Skip to content
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

feat: Update Operator SDK version strategy #1250

Conversation

mateusoliveira43
Copy link
Contributor

The goal of this PR is to create a strategy (document or script) for updating Operator SDK version in the project.

My goal was to have all operator generated files in a separate folder (inspired by dora-metrics/pelorus#1045), but helm and Go Operator SDK structures are different, its not the best idea to try to put Go generated files in a separate folder.

The idea is: in temporaries folders, create Operator SDK structure using the current Operator SDK version and the version which we want to upgrade it to, following these steps:
operator-sdk init --project-name=oadp-operator --repo=github.com/openshift/oadp-operator --domain=openshift.io
operator-sdk create api --group oadp --version v1alpha1 --kind DataProtectionApplication --resource --controller
operator-sdk create api --group oadp --version v1alpha1 --kind CloudStorage --resource --controller

Then generate a diff file and apply changes to repo code.
It seems to work operator-framework/operator-sdk#6628

There are still a few points to adjust, like: when do we update boilerplate year? What to update in go.mod? Create another Makefile? ( the example added can be run with make -f oadp.mk help)

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Dec 1, 2023
Copy link

openshift-ci bot commented Dec 1, 2023

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

Copy link

openshift-ci bot commented Dec 1, 2023

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mateusoliveira43
Once this PR has been reviewed and has the lgtm label, please assign jmontleon for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

op.diff Outdated
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

example of diff file between current and next operator sdk version structures

@mateusoliveira43
Copy link
Contributor Author

Should we update hack/boilerplate.go.txt to match this?

oadp-operator/LICENSE

Lines 179 to 191 in 0347669

Copyright 2016 Red Hat, Inc.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

.dockerignore Outdated
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of creating new Makefile, we could just add our commands to end of the file, like this. This should avoid patching problems

@@ -40,7 +40,7 @@ func isObjectOurs(scheme *runtime.Scheme, object client.Object) bool {
return false
}
gvk := objGVKs[0]
if gvk.Group == oadpv1alpha1.GroupVersion.Group && gvk.Version == oadpv1alpha1.GroupVersion.Version && gvk.Kind == oadpv1alpha1.Kind {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this change is ok or we only care about DPA objects here?

@mateusoliveira43
Copy link
Contributor Author

For every file accepted to change name, run grep command to check doc occurrences and change them as well

Client client.Client
Scheme *runtime.Scheme
Log logr.Logger
EventRecorder record.EventRecorder
}

//TODO!!! FIX THIS!!!!
//TODO!!! FIX THIS!!!!?
// TODO change buckets to cloudstorages?
Copy link
Contributor Author

@mateusoliveira43 mateusoliveira43 Dec 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this and leases role need updating

@mateusoliveira43
Copy link
Contributor Author

also run operator-sdk create webhook command after operator-sdk create api?

@@ -28,8 +28,6 @@ var (
// GroupVersion is group version used to register these objects
GroupVersion = schema.GroupVersion{Group: "oadp.openshift.io", Version: "v1alpha1"}

Kind = "DataProtectionApplication"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we wanna add kind back and add to schemebuilder line 32?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think not, I believe this was used only as a constant here

if gvk.Group == oadpv1alpha1.GroupVersion.Group && gvk.Version == oadpv1alpha1.GroupVersion.Version && gvk.Kind == oadpv1alpha1.Kind {

I believe the kind is get from theses structs name https://github.com/openshift/oadp-operator/blob/master/api/v1alpha1/oadp_types.go#L281, in each file

@mpryc
Copy link
Contributor

mpryc commented Dec 6, 2023

The idea is really nice, may be tricky to maintain with more diffs.

We have something like that in other project, right?
https://github.com/dora-metrics/pelorus/tree/master/scripts/pelorus-operator-patches

The benefit is that we can always re-generate operator starting from scratch.

This is fine for operator where there is not a huge number of changes to the initial files generated by the operator-sdk however in the case of oadp-operator where majority of the code is implemented within that generated initial files this may be very hard to maintain, especially when we are talking later about backports to older releases.

What about using kustomize files instead of patches whenever applicable ?

@mateusoliveira43
Copy link
Contributor Author

@mpryc similar yes, but we will not have patch files here. Its terrible developer experience (editing a diff file instead of a yaml file, for example).

We would re-generate files only when we want to update opeartor-sdk version, then we would create a diff file (not tracked by git), and then apply it and then open a PR for that action.

kustomize files can be an option, but not for all things I think. Makefile may be updated, for example. And that is the thing I think we need to be more careful: editing generated files. So, when we update then, it is a smooth experience. Maybe just adding new things to the end of those files can be enough to avoid patching errors

@openshift-merge-robot
Copy link

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.

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 10, 2024
@openshift-bot
Copy link

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

@openshift-ci openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 10, 2024
@mateusoliveira43
Copy link
Contributor Author

/remove-lifecycle stale
Still want to work on this

@openshift-ci openshift-ci bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 10, 2024
Copy link

openshift-ci bot commented Jun 19, 2024

@mateusoliveira43: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/4.16-e2e-test-kubevirt-aws 756db8e link true /test 4.16-e2e-test-kubevirt-aws
ci/prow/4.16-e2e-test-aws 756db8e link true /test 4.16-e2e-test-aws
ci/prow/4.16-ci-index 756db8e link true /test 4.16-ci-index
ci/prow/4.15-e2e-test-kubevirt-aws 756db8e link true /test 4.15-e2e-test-kubevirt-aws
ci/prow/4.15-ci-index 756db8e link true /test 4.15-ci-index
ci/prow/4.15-images 756db8e link true /test 4.15-images
ci/prow/4.16-images 756db8e link true /test 4.16-images
ci/prow/4.15-e2e-test-aws 756db8e link true /test 4.15-e2e-test-aws

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.

@openshift-bot
Copy link

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

@openshift-ci openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 18, 2024
@kaovilai
Copy link
Member

unstale?

@mateusoliveira43
Copy link
Contributor Author

@kaovilai going to close this one and create small PRs that together do the same

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants