-
Notifications
You must be signed in to change notification settings - Fork 22
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
Don't use fields of ToolchainCluster spec #428
Don't use fields of ToolchainCluster spec #428
Conversation
Quality Gate passedIssues Measures |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #428 +/- ##
==========================================
+ Coverage 77.36% 77.47% +0.11%
==========================================
Files 49 49
Lines 2010 2007 -3
==========================================
Hits 1555 1555
+ Misses 401 398 -3
Partials 54 54
|
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.
thanks for the detailed explanation, but this is only a change in the test package, so you could easily go ahead and remove it from the api repo.
Or do you think that there is gonna be more places where we rely on the fields in host/member/e2e/reg-service repos?
That's a good point. There is a number of places in e2e and ksctl, but host operator, member operator and registration service don't see any changes but the update in versions and CRD yamls. I will take a look at how the "PR train" could be simplified. |
Yeah, in this case, I wouldn't be worried so much. |
This PR prepares
toolchain-common
for removal of most fields from theToolchainCluster
spec. The only field that will eventually remain is the secret reference. All the rest of the fields have either been moved to the status of theToolchainCluster
already or are part of the kubeconfig that is stored in the referenced secret.NOTE: that this PR does NOT update the dependency to the API. That is to avoid breakage during the relatively long time it will take to update all the components with the necessary changes. Once we merge this PR, I will create a number of additional PRs in the rest of the components that will use the new version of
toolchain-common
and make necessary updates in the components to not use the outdated fields ofToolchainCluster
. Only once those PRs are merged, we can go ahead and merge the PR to remove the fields from the API, followed by another set of PRs to updatetoolchain-common
and subsequenlty all the other components to that new version.Doing it this way will ensure that any changes that happen in
api
and/ortoolchain-common
in the meantime will not be affected by the breaking change.