Skip to content

Consider aligning Cluster API conditions to upstream conditions #7635

@sbueringer

Description

@sbueringer

A while back an upstream KEP was merged which tries to standardize conditions: https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1623-standardize-conditions
(corresponding implementation: kubernetes/kubernetes#90454)

The diff to our conditions is:

  • upstream has an additional optional ObservedGeneration field
  • Cluster API has an additional optional Severity field

I think it could be interesting to consider if we want to add the optional ObservedGeneration field to our Conditions.

godoc:

	// If set, this represents the .metadata.generation that the condition was set based upon.
	// For instance, if .metadata.generation is currently 12, but the .status.condition[x].observedGeneration is 9, the condition is out of date
	// with respect to the current state of the instance.
	// +optional
	ObservedGeneration int64 `json:"observedGeneration,omitempty" protobuf:"varint,3,opt,name=observedGeneration"`

Recently there was a thread about this in #sig-api-machinery https://kubernetes.slack.com/archives/C0EG7JC6T/p1666371350588619

/area api

[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

Metadata

Metadata

Labels

area/apiIssues or PRs related to the APIskind/api-changeCategorizes issue or PR as related to adding, removing, or otherwise changing an APIpriority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.triage/acceptedIndicates an issue or PR is ready to be actively worked on.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions