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

applyconfiguration-gen generates incorrect Extract...Status() #173

Open
Gchbg opened this issue May 14, 2024 · 2 comments
Open

applyconfiguration-gen generates incorrect Extract...Status() #173

Gchbg opened this issue May 14, 2024 · 2 comments

Comments

@Gchbg
Copy link

Gchbg commented May 14, 2024

This has tested with 0.29.4, 0.30.0, and the current master branch.

applyconfiguration-gen generates (experimental!) ExtractXYZ() and ExtractXYZStatus() functions that take an object and deliver an applyconfiguration that only has those fields prefilled that are owned by a given field manager.

The ExtractXYZStatus() does not extract conditions correctly. In the status of our CRD we have standard Kubernetes conditions:

	// +patchStrategy=merge
	// +patchMergeKey=type
	// +optional
	Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`

In an object that has one condition set by a controller using SSA, a subsequent reconcile by the same controller (using the same field manager value in both cases) calls ExtractXYZStatus(), which extracts all other owned fields correctly, but the Conditions slice is always nil in the output applyconfiguration. This has the effect that every time the controller wants to set any other field in the status, it inadvertantly clears its own conditions.

Instead I would expect that the applyconfiguration contains the condition previously set by the same controller.

@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle stale
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 12, 2024
@Gchbg
Copy link
Author

Gchbg commented Aug 12, 2024

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 12, 2024
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

No branches or pull requests

3 participants