-
Notifications
You must be signed in to change notification settings - Fork 120
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
Add migration logic for moving from in-tree to out-of-tree #484
Conversation
/hold |
/hold until this is tested through the Gardener |
/unhold open for review |
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.
@prashanth26 Thanks for the PR! I have some minor comments. However, the main one is regarding passing machine class client in the MigrateMachineClass
call.
This driver call will be called by the Machine Controller to try to perform a machineClass migration for an unknown machineClass Kind. This helps in migration of one kind of machineClass to another kind. For instance an machineClass custom resource of `AWSMachineClass` to `MachineClass`. | ||
|
||
- On successful migration of machine class the Provider MUST reply `0 OK` (or) `nil` error. | ||
- `MigrateMachineClassRequest` expects the `ClassSpec` containing the `type ClassSpec struct`. It also expects a `MachineClass` client that can be used to communicate with the cluster containing the machine objects. It also passes the `Namespace` where these objects can be found. |
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.
Why not pass the existing provider machine class as a parameter and expect a filled up generic machine class object in return? If type is a problem, it could be just bytes with the callee decoding it.
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 have made these changes here - a646f1a#diff-40981fe61397ebaeddeec79632a3e1c4R141-R148
|
||
- On successful migration of machine class the Provider MUST reply `0 OK` (or) `nil` error. | ||
- `MigrateMachineClassRequest` expects the `ClassSpec` containing the `type ClassSpec struct`. It also expects a `MachineClass` client that can be used to communicate with the cluster containing the machine objects. It also passes the `Namespace` where these objects can be found. | ||
- `MigrateMachineClass` is responsible for creating the new `CR` of the new kind (MachinClass) with the same name as the previous one. It also responsible for annotating the old machineClass CR with an migrated annotation. |
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.
Why not just receive the filled up generic machine class object from the MigrateMachineClass
and actually create the CR instance in the caller library?
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 reason I have been avoiding this is because, then this code of annotating the old machine class would go into the current reconciliation loop. And this would mean multiple different calls might have to be made to different machineClass clients while annotation, however keeping it inside the provider spec it would be easier to determine which call to exactly make. However, now what I re-think about it. It seems fine to me.
Let me try making such changes with the new GCP provider and test it out. And see if I face any difficulties.
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.
👍
The existing in-tree code already has the logic based on the old typed machine classes. So, this would be one more place. Also, this would be only for migration, we can phase this code out via deprecation over a couple of releases. But it if is there in the providers, then phasing it out also is then multiplied by the number of providers.
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.
Yes makes sense.
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 have moved the common logic into this pkg with this commit. Also the leftover at the provider can be seen here at the provider. I hope this is what you meant.
@amshuman-kr & @hardikdr - I have made all the requested code changes to the best of my knowledge, let me know if I missed something. Also, I have added a few tests for verifying the migration code path. |
@prashanth26 tests are failing, can you please check. |
@hardikdr - Sorry, missed out some things while running the final tests. Seems to be working now. |
@prashanth26 It'd be nice to squash & re-arrange a few of the commits in a meaningful order. @amshuman-kr @ggaurav10 Can you please take a final look and approve if possible? |
/lgtm /hold till commits are squashed. |
Yes Hardik. Shall do that once all comments are addressed. |
- Any changes/updates to class.Kind propagates top-down without rolling updates - Ignore reconciling machines with unknown ClassKind at MCM - Updated docs to reflect these changes - Updated old machine class finalizers - Introduced a new flag to delete old machine classes on migration
- The machineClass controllers add finalizer only when reference is present, and removes it otherwise - There is also logic for setting the deletion timestamp if migration annotation and delete-migrated-machine-class flag is set
/unhold |
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.
lgtm
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.
LGTM
Thank you, guys. Will merge it once the tests pass. |
What this PR does / why we need it:
This PR adds migration logic for moving from in-tree to out-of-tree
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note: