Status annotations #380
Closed
Status annotations #380
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jacobweinstock
added
the
do-not-merge
The previous method of provisioning state relied on the AllowPXE field of the Hardware spec. This overloads this field and makes it difficult to understand state. This is also problematic when gitops is employed with Hardware objects. Annotations are purpose built for state and work well with CAPI. FYI, fields in the status object state are not maintained during CAPI move/pivot operations. There is also at least one other known bare metal CAPI provider that uses this pattern very successfully. Signed-off-by: Jacob Weinstock <[email protected]>
jacobweinstock
force-pushed
the
status-annotations
branch
from
466472a to
93b53a0
Compare
|
resolved by #407 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Important
This builds off of PR #379 and must wait for it to be merged.
The previous method of provisioning state relied on the AllowPXE field of the Hardware spec. This overloads this field and makes it difficult to understand state. This is also problematic when gitops is employed with Hardware objects.
Annotations are purpose built for state and work well with CAPI. FYI, fields in the status object state are not maintained during CAPI move/pivot operations so they are not an option. There is also at least one other known bare metal CAPI provider that uses this pattern very successfully.
Why is this needed
Fixes: #
How Has This Been Tested?
How are existing users impacted? What migration steps/scripts do we need?
Checklist:
I have: