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.
I would explicitly mention that Dockerfile changes + ocp-build-data / cachito PR should be merged +/- at the same time, otherwise builds will start failing.
|
|
||
| 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.
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.goto be implemented similar to othercmd/*/main.gopkg/driver/<new-driver-name>/<new-driver-name>.goto 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 letgeneratorgenerate yamls inassets/overlays/<new-driver-name>/generated/same (or almost same) as assets fromlegacy/
There was a problem hiding this comment.
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).
| 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.
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.
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 |
openshift-ci
bot
changed the title
| 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.
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.
Added some wording for this.
|
|
||
| ### 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.
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.
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.
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 |
openshift-ci
bot
added
the
approved
|
@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