⚠️ Remove Metal3Machine owner reference from BMH #1742
Conversation
|
[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.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
metal3-io-bot
added
the
size/M
|
/hold |
metal3-io-bot
added
the
do-not-merge/hold
kashifest
changed the title
metal3-io-bot
added
the
do-not-merge/work-in-progress
|
/test metal3-ubuntu-e2e-integration-test-main |
1 similar comment
|
/test metal3-ubuntu-e2e-integration-test-main |
|
/test ? |
|
@kashifest: The following commands are available to trigger required jobs:
The following commands are available to trigger optional jobs:
Use
In 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 kubernetes/test-infra repository. |
|
@kashifest |
Yes, I am doing the same thing here, I didn't notice you had the same thing in another PR, didnt mean to over step. I am currently testing this since it seems to not passing the pivot scenario so it would need more changes. I am also ok to close my one if you have progressed more. |
|
@kashifest |
kashifest
force-pushed
the
remove/bmh-ownerRef
branch
from
0e5ff05 to
cfbdb57
Compare
|
/test metal3-ubuntu-e2e-integration-test-main |
1 similar comment
|
/test metal3-ubuntu-e2e-integration-test-main |
Metal3Machine should not own BMH. It should consume it and release it when not needed. we already put a M3M consumer reference on BMH. This also would mean that for pivoting use cases we must add the clusterctl move labels in the CRDs. Otherwise BMH wont be pivoted to target clusters. Signed-off-by: Kashif Khan <[email protected]>
kashifest
force-pushed
the
remove/bmh-ownerRef
branch
from
cfbdb57 to
6c7d0c1
Compare
|
/test metal3-ubuntu-e2e-integration-test-main |
1 similar comment
|
/test metal3-ubuntu-e2e-integration-test-main |
|
/test metal3-centos-e2e-integration-test-main |
|
/test ? |
|
@kashifest: The following commands are available to trigger required jobs:
The following commands are available to trigger optional jobs:
Use
In 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 kubernetes-sigs/prow repository. |
|
/test metal3-ubuntu-e2e-feature-test-main-features |
|
/test metal3-e2e-clusterctl-upgrade-test-main |
kashifest
changed the title
metal3-io-bot
removed
the
do-not-merge/work-in-progress
kashifest
changed the title
|
/hold cancel |
metal3-io-bot
removed
the
do-not-merge/hold
|
/test metal3-centos-e2e-feature-test-main-pivoting |
|
/test metal3-e2e-clusterctl-upgrade-test-main |
|
/test metal3-centos-e2e-feature-test-main-pivoting |
3 similar comments
|
/test metal3-centos-e2e-feature-test-main-pivoting |
|
/test metal3-centos-e2e-feature-test-main-pivoting |
|
/test metal3-centos-e2e-feature-test-main-pivoting |
|
/test metal3-ubuntu-e2e-feature-test-main-pivoting |
2 similar comments
|
/test metal3-ubuntu-e2e-feature-test-main-pivoting |
|
/test metal3-ubuntu-e2e-feature-test-main-pivoting |
|
/test metal3-centos-e2e-feature-test-main-pivoting |
|
/test metal3-ubuntu-e2e-feature-test-main-pivoting |
2 similar comments
|
/test metal3-ubuntu-e2e-feature-test-main-pivoting |
|
/test metal3-ubuntu-e2e-feature-test-main-pivoting |
|
/test metal3-centos-e2e-feature-test-main-pivoting |
2 similar comments
|
/test metal3-centos-e2e-feature-test-main-pivoting |
|
/test metal3-centos-e2e-feature-test-main-pivoting |
|
/hold |
metal3-io-bot
added
the
do-not-merge/hold
There was a problem hiding this comment.
Thank you for doing this!
How should we handle upgrades? From what I can see, we would not automatically remove owner references that are already there, so it would be up to the user to remove them after upgrade I guess.
One alternative we could consider is to keep the code that removes the owner reference when deleting the M3M for one minor release cycle. Then we can say that users must do a rollout in order to get rid of the owner references, or they can do it manually if they prefer. What do you think?
Yes we can do that. I thought of writing a doc update and ask users to remove it manually. We can also keep the removal code for one minor cycle and ask for rollout. |
|
This will not make CAPM3 1.9, will it? @kashifest |
Discussed offline, this is only going to have a heads-up in 1.9, actual fixes will go to 1.10. Changed milestone accordingly. |
Metal3Machine should not own BMH. It should consume it and release it when not needed. we already put a M3M consumer reference on BMH. This also would mean that for pivoting use cases we must add the clusterctl move labels in the CRDs. Otherwise BMH wont be pivoted to target clusters.
clusterctl.cluster.x-k8s.io/movelabel or theclusterctl.cluster.x-k8s.io/move-hierarchylabel to make sure BMH is pivoted to target cluster and removed from the source.clusterctl.cluster.x-k8s.io/moveandclusterctl.cluster.x-k8s.io/move-hierarchylabels could be applied to single objects or at the CRD level (the label applies to all the objects).