search

operator-framework / enhancements

Apache License 2.0
9 stars 40 forks source link

Operator Conditions Enhancement #42

Closed awgreene closed 4 years ago

awgreene commented 4 years ago

Created as a stripped down version of #23 due to reduce size and complexity.

exdx commented 4 years ago

I'm glad we went with this stripped down version after all the back and forth -- it reads simply and is intuitive.

As part of our upstream initiative we can think about expanding this feature for more flexibility in the future but this is great for an MVP.

/lgtm

ecordell commented 4 years ago

/approve

kevinrizza commented 4 years ago

/lgtm

njhale commented 4 years ago

/lgtm

njhale commented 4 years ago

/approve

Jamstah commented 4 years ago

In my experience, the most common condition is Ready, I was surprised to see this proposal doesn't include it.

I don't know what OLM currently uses to determine readiness (pod status?), but allowing an operator to add to the checks seems like an obvious addition.

awgreene commented 4 years ago

Hello @Jamstah, thank you for the review on this PR!

In my experience, the most common condition is Ready, I was surprised to see this proposal doesn't include it. I don't know what OLM currently uses to determine readiness (pod status?), but allowing an operator to add to the checks seems like an obvious addition.

This is a great observation and one that I considered. As of today, OLM identifies readiness by inspecting the states of the resources that define the operator (deployments, CRD availability, RBAC existing, etc...). I haven't identified a usecase where an Operator would want to override OLM's assessment but it could exist. That being said, I hope to implement this feature in a way that would allow OLM to easily extend to support to additional conditions as the usecases arise.

openshift-ci-robot commented 4 years ago

@shawn-hurley: GitHub didn't allow me to request PR reviews from the following users: awgreene.

Note that only operator-framework members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to [this](https://github.com/operator-framework/enhancements/pull/42#discussion_r489122944): >@bparees wht are your thoughts on the name of this resource? It seems much to generic to me but wanted a second opinion. > > >/cc @awgreene Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.