-
Notifications
You must be signed in to change notification settings - Fork 78
Introduce new OperatorCondition CRD #74
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
Conversation
// +kubebuilder:storageversion | ||
// +kubebuilder:subresource:status | ||
// OperatorCondition is a Custom Resource of type `OperatorCondition` which is used to convey information to OLM about the state of an operator. | ||
type OperatorCondition struct { |
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.
Condition struct was already defined.
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.
is the user facing documentation on how to use this located in another PR? or is it yet to be written?
We should probably document this here and link that PR here so that we can merge both of them together/at least one right after the other. |
pkg/operators/v1/condition_types.go
Outdated
|
||
// OperatorConditionSpec allows a cluster admin to convey information about the state of an operator to OLM, potentially overriding state reported by the operator. | ||
type OperatorConditionSpec struct { | ||
Overrides []Condition `json:"overrides,omitempty"` |
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.
Should we add a TODO on the Condition
type to migrate to metav1.Condition
when we move everything to k8s 1.19+?
Is there anything that would prevent us from doing that? (e.g. a breaking change)
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.
We could use the metav1.Condition but we should be recognize that OLM's condition type has different fields:
- OLM's Condition has the
LastUpdateTime
field. - The metav1.Condition has the
ObservedGeneration
field.
If we plan to update this struct to use the metav1.Condition
we will have to handle any CRs that have set the LastUpdateTime
field. Thoughts?
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 would definitely opt for using metav1.Condition
directly. We should diverge as little as possible. If we find that LastUpdateTime
is actually useful, then we can create a composite struct that embeds metav1.Condition
.
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.
to add to this, I was planning on replacing the Condition
struct you're using w/ metav1.Condition
at some point down the road as well.
accde41
to
40a9220
Compare
2fc06a7
to
a8a46e2
Compare
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
This commit introduces the OperatorCondition CRD which is used by an operator to communicate state to OLM.
a8a46e2
to
775018b
Compare
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
/approve |
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
/QE-approved |
This commit introduced the OperatorCondition CRD which allows operators
to communicate advanced state directly with OLM.