openshift
[OSDOCS-4318]: Adds steps to use STS for 3rd-party Operators
Version(s): 4.8+ (needs SME verification)
Issue: OSDOCS-4318
Link to docs preview:
- Configuring an Operator to use Amazon Web Services Secure Token Service (OLM book)
- Configuring an Operator to use Amazon Web Services Secure Token Service (AWS EFS CSI section)
QE review:
- [ ] QE has approved this change.
Additional information: WIP draft with several open items
🤖 Updated build preview is available at: https://51541--docspreview.netlify.app
Build log: https://circleci.com/gh/ocpdocs-previewbot/openshift-docs/8546
I am not sure why the output currently has so many step 1.s but I guess I will figure that out later. This is edited based on initial feedback, still has some open questions and missing details (see // comments in file view).
Most recent push removes conditions and assumes the user needs to create a CR no matter what. (I left the lines in block comments for now in case we reconsider that. Block comments also cause the numbering to restart but will be fixed when finalized)
The branch/enterprise-4.13 label has been added to this PR.
This is because your PR targets the main branch and is labeled for enterprise-4.12. And any PR going into main must also target the latest version branch (enterprise-4.13).
If the update in your PR does NOT apply to version 4.13 onward, please re-target this PR to go directly into the appropriate version branch or branches (enterprise-4.x) instead of main.
@jianping-shu this is ready for verification, PTAL :bow:
Cc: @duanwei33 - this PR replaces the content you verified in #44136 last year.
![openshift-ci[bot] avatar](https://avatars.githubusercontent.com/in/91280?v=4 "Published by a pub.dev verified publisher"){kind=small}
@jeana-redhat One more thing came into my mind, shall we still keep the EFS CredentialsRequest YAML file as before? Otherwise the user can't get the info about permission/serviceAccountNames as in the original yaml example. So in the procedure of AWS Elastic File Service CSI Driver Operator, we shall NOT do "oc get credentialsrequest", instead we shall follow the original step "2. Create and save an EFS CredentialsRequest YAML file..." as in https://github.com/openshift/openshift-docs/pull/44136,
@jianping-shu Does the user need to know the ServiceAccount name / permissions required if processing the CR with ccoctl? I think having the operator install the CR for the user to oc get would be preferred it so that the documentation doesn't need to be updated when the permissions change in the CredentialsRequest? What do you think?
@abutcher Yes, if the CR exists, that should be the ideal design and right way to go.
But CR didn't exist when we performed the STS step in today's testings.
@duanwei33 helped to try the procedure on an aws cluster whose cco mode is 'passthrough' After performed step 2 of Installing the AWS EFS CSI Driver Operator, The CR openshift-aws-efs-csi-driver was NOT created. After performed step 4 Install the AWS EFS CSI Driver (step 3 is NOT needed since not STS). The CR openshift-aws-efs-csi-driver and its corresponding secret were created successfully
I had a test on aws sts cluster. After performed step 2 of Installing the AWS EFS CSI Driver Operator, The CR openshift-aws-efs-csi-driver was NOT created. Then I bypassed step 3 for STS (to find out if/when CR created) and performed step 4 Install the AWS EFS CSI Driver directly. The CR openshift-aws-efs-csi-driver was still NOT created, and efs csi operator pods can't start successfully jianpingshu@jshu-mac OSDOCS-4318 % oc -n openshift-cluster-csi-drivers get pod | grep aws-efs-csi-driver-controller aws-efs-csi-driver-controller-69d45bb9c-k5zzf 0/4 ContainerCreating 0 77m aws-efs-csi-driver-controller-69d45bb9c-kxfc5 0/4 ContainerCreating 0 77m
Seems AWS EFS CSI Driver has the different behaviors when cco mode are in non-manual and manual. But after step 2 i.e. installing operator from operatorHub, CR doesn't exist yet so the current procedure can't work as expected. For short term solution, I think maybe we can still paste EFS CredentialsRequest YAML file on the doc as before. For long term, we can suggest the developers of 3rd party operator to follow the way of inserting CR as soon as installing the operator.
Thanks for the detailed explanation @jianping-shu, it is really helpful! I will think about how to get this taken care of in docs for now :slightly_smiling_face:
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
PR needs rebase.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@jianping-shu that makes sense. Probably for the best, I failed twice trying to fix this rebase file-by-file, so a fresh start is in order anyway :)
The branch/enterprise-4.14 label has been added to this PR.
This is because your PR targets the main branch and is labeled for enterprise-4.13. And any PR going into main must also target the latest version branch (enterprise-4.14).
If the update in your PR does NOT apply to version 4.14 onward, please re-target this PR to go directly into the appropriate version branch or branches (enterprise-4.x) instead of main.
https://issues.redhat.com/browse/OSDOCS-4318?focusedId=22538844&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-22538844