Skip to content
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

Change status conditions to follow conventions #4976

Conversation

thetechnick
Copy link

Description

Currently prometheus-operator status conditions don't follow kubernetes
api conventions. This PR replaces the custom condition type with a
definition from kubernetes/apimachinery.

It also uses helper functions from apimachinery, where appropriately to
reduce code duplication.

This change is to be considered API breaking(!), dependent on release
management and consistency guarantees.

Follow up from #4975

Signed-off-by: Nico Schieder nschieder@redhat.com

Type of change

What type of changes does your code introduce to the Prometheus operator? Put an x in the box that apply.

  • CHANGE (fix or feature that would cause existing functionality to not work as expected)
  • FEATURE (non-breaking change which adds functionality)
  • BUGFIX (non-breaking change which fixes an issue)
  • ENHANCEMENT (non-breaking change which improves existing functionality)
  • NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Changelog entry

Please put a one-line changelog entry below. This will be copied to the changelog file during the release process.

changed status conditions to be consistent with kubernetes api conventions

@thetechnick thetechnick requested a review from a team as a code owner August 19, 2022 14:44
Currently prometheus-operator status conditions don't follow kubernetes
api conventions. This PR replaces the custom condition type with a
definition from kubernetes/apimachinery.

It also uses helper functions from apimachinery, where appropriately to
reduce code duplication.

This change is to be considered API breaking(!), dependent on release
management and consistency guarantees.

Signed-off-by: Nico Schieder <nschieder@redhat.com>
@thetechnick thetechnick force-pushed the conventions-conform-conditions branch from ce027a3 to 04d47de Compare August 19, 2022 15:13
Copy link
Contributor

@JoaoBraveCoding JoaoBraveCoding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@apahim
Copy link

apahim commented Aug 29, 2022

@simonpasquier can you please take a look?

Copy link
Contributor

@simonpasquier simonpasquier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I see where you're coming from, my first remark is that we can't change the actual API because the CRD version is v1. Having said that, I'm fine with adding things like observedGeneration and improving the API documentation.

@thetechnick
Copy link
Author

Closing in favor of a follow up PR just containing observedGeneration to not break backwards compatibility.
Thanks everyone for having a look!

@thetechnick thetechnick closed this Sep 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants