-
Notifications
You must be signed in to change notification settings - Fork 459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move steps for migrating code to csi-operator to ocp enhancements #1644
Move steps for migrating code to csi-operator to ocp enhancements #1644
Conversation
But once your operator has been changed to conform to new code in csi-operator repo, You need to perform following additional steps: | ||
|
||
1. Make sure that `Dockerfile.<operator>` at top of the `csi-operator` tree refers to new location of code and not older `legacy/<operator>` location.See example of existing Dockerfiles. | ||
2. After your changes to `csi-operator` are merged, you should remove the old location from cachito - https://github.com/openshift-eng/ocp-build-data/pull/4219 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would explicitly mention that Dockerfile
changes + ocp-build-data / cachito PR should be merged +/- at the same time, otherwise builds will start failing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
|
||
So in previous section we merely copied existing code from operator’s own repository into `csi-operator` repository. We did not change anything. | ||
|
||
But once your operator has been changed to conform to new code in csi-operator repo, You need to perform following additional steps: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the notion of "to conform to new code" deserves more words/details. I'd highlight the following topics:
cmd/<new-driver-name>/main.go
to be implemented similar to othercmd/*/main.go
pkg/driver/<new-driver-name>/<new-driver-name>.go
to be implemented similar to otherpkg/driver/*/*
assets/overlays/<new-driver-name>/base/
andassets/overlays/<new-driver-name>/patches/
to be populated with such yaml files to letgenerator
generate yamls inassets/overlays/<new-driver-name>/generated/
same (or almost same) as assets fromlegacy/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not want to tie this enhancement to code and asset structure. What if that changes? An enhancement is not the right place to document implementation details TBH (at least not in great detail).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, agreed, let's keep it vague.
Make a PR to openshift/release repository to build the operator from csi-operator. For example - https://github.com/openshift/release/pull/46233. | ||
|
||
1. Update also `storage-conf-csi-<operator>-commands.sh`, the test manifest will be at a different location. | ||
2. Make sure that rehearse jobs for both older versions of operator and newer versions of operator pass. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a better way to search for rehearsal job names other than looking at jobs in PRs and history? Maybe we could expand on this step a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think when you do /pj-rehearse
it doe list the jobs and then you can choose and run.
/retitle Move steps for migrating code to csi-operator to ocp enhancements |
2. Ask ART for a scratch build. Make sure you can install a cluster with that build. | ||
|
||
``` | ||
oc adm release new \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not applicable to OLM based operators - can we have a note or pointer here on testing the scratch build with OLM?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some wording for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of minor comments, but this is great, thanks for putting it together!
|
||
### Add Dockerfiles for building images from new location | ||
|
||
Place a `Dockerfile.<operator>` and `Dockerfile.<operator>.test` at top of csi-operator tree and make sure that you are able to build an image of the operator from csi-operator repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We consolidated the various Dockerfile.<operator>.test
files into a single Dockerfile.test
, there generally shouldn't be any need to add a new one unless some operator is doing more than FROM src
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed.
Co-authored-by: Roman Bednář <rbednar@redhat.com>
Co-authored-by: Jonathan Dobson <dobsonj@gmail.com>
/lgtm |
@@ -514,6 +514,8 @@ azure-disk-csi-driver-operator=<the scratch build> \ | |||
oc adm release extract --command openshift-install quay.io/jsafrane/scratch:release1 | |||
``` | |||
|
|||
This step is only applicable for CVO based operators and not OLM based operators. For OLM based operator - either an image can be built locally and deployed using your personal index image or you can ask ART team for a scratch image when you open `ocp-build-data` PR and proceed to include that image in your personal index image. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a little too condensed. Can you actually include the operator image in index? I think you can include only bundles.
What we actually do is that we specify the operator image in ClusterServiceVersion, make a bundle out of it, and include the bundle in the index image. For that we have a script, so the scratch image would be used like this:
./create-efs-bundle registry.ci.openshift.org/ocp/4.9:aws-efs-csi-driver <OPERATOR_SCRATCH_IMAGE> quay.io/<my-repo>/efs-bundle quay.io/<my-repo>/efs-index
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jsafrane The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@gnufied: all tests passed! Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
Document process of migrating code to csi-operator
cc @openshift/storage