OSASINFRA-3980: Migrate asset generation to ocp-manifests#386
OSASINFRA-3980: Migrate asset generation to ocp-manifests#386stephenfin wants to merge 6 commits intoopenshift:mainfrom
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@stephenfin: This pull request references OSASINFRA-3980 which is a valid jira issue. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
cfbf0e2 to
873cc7d
Compare
873cc7d to
696084c
Compare
0ab1345 to
3bc3a76
Compare
|
@stephenfin: This pull request references OSASINFRA-3980 which is a valid jira issue. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
3bc3a76 to
3177993
Compare
|
/test e2e-openstack-capi-techpreview |
4aff9d1 to
09eef30
Compare
As noted by the cloud team: None of those are required. They were actually never required because they're CVO annotations, and these manifests aren't being handled by CVO. This helps reduce the diff between what we're generating with our current tooling at the new manifests-gen tooling in the future. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The VAP simply prevents the deletion of the InfraCluster resource and is a gap in our previous tooling: manifest-gen has had this functionality for a few years [1]. By adding it now, we minimise the size of our diff when we migrate to that tool. [1] openshift/cluster-capi-operator#196 Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This lets us work like everyone else. 'Makefile' changes are simply [1] appended to the end of our existing 'openshift/Makefile' file, while the 'openshift/tools/tools.go' and 'openshift/tools/go.mod' are taken from [2] and [3], respectively. [1] https://github.com/openshift/cluster-api-provider-gcp/blob/release-4.22/openshift/Makefile [2] https://github.com/openshift/cluster-api-provider-gcp/blob/release-4.22/openshift/tools/tools.go [2] https://github.com/openshift/cluster-api-provider-gcp/blob/release-4.22/openshift/tools/go.mod Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Invoke our new makefile target. In the future, this should happen automatically. ❯ make -C openshift ocp-manifests PROVIDER_VERSION=v0.14.0 Because the previous manifest file was a (very) large YAML file with a serialized YAML file within, we need to do some manipulation and use a semantic diff tool (dyff [1]) to compare the output. This was achieve like so: ❯ yq '.data.components' < openshift/manifests/0000_30_cluster-api-provider-openstack_04_infrastructure-components.yaml > old.yaml ❯ dyff between old.yaml openshift/capi-operator-manifests/default/manifests.yaml This highlights the addition of empty `.status` and `.spec.strategy` keys to the `capo-controller-manager` Deployment and some reordering changes but nothing further. [1] https://github.com/homeport/dyff Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Rework our OpenShift-specific Dockerfile and Makefile to align with those used for other providers. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This is now handled by CCAPIO's manifest-gen. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
09eef30 to
e2838b7
Compare
|
@stephenfin: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
This aligns us with the other providers and should ease the maintenance burden somewhat.
Note
The series has been reworked to reflect this change. See the below for other examples of providers migrating to the newmanifests-genis currently being rewritten, so there's a good chance we won't end up merging a lot of this. We likely want the initial patch to removeMakefiletargets along with theDockerfilechanges, however.manifests-gen(albeit from the oldmanifests-gen, rather than something in-tree):