-
Story
-
Resolution: Done
-
Normal
-
None
-
None
-
Quality / Stability / Reliability
-
False
-
None
-
False
-
None
-
3
-
None
-
None
-
CLOUD Sprint 216, CLOUD Sprint 217
User Story
As a developer I want consistent APIs so that our code is easier to maintain. To support this effort, the provider-specific conditions that are represented in the the provider status for each specific provider should be refactored to use the common metav1.Condtion type from upstream kubernetes.
Background
Currently our provider status definitions in openshift/api all contain provider-specific api types for their condition fields. These could be factored out in favor of the common Condition type from the upstream kubernetes project.
For context, see this discussion thread
Steps
- Refactor the various providers in the openshift/api repo to use metav1.Condition instead of their provider-specific conditions
- Review provider actuator code to ensure that there is no breakage
- Review MAO code to ensure there is no breakage
Stakeholders
- OpenShift Engineering
Definition of Done
- api types updated
- Docs
- this should not require a docs change, but we should review the examples we have in product docs to ensure accuracy.
- Testing
- this should not require a specific testing to verify