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

Improve/adapt Knative defaulting and validation for K8s object types #14774

Open
ReToCode opened this issue Jan 10, 2024 · 3 comments
Open

Improve/adapt Knative defaulting and validation for K8s object types #14774

ReToCode opened this issue Jan 10, 2024 · 3 comments
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. triage/accepted Issues which should be fixed (post-triage)

Comments

@ReToCode
Copy link
Member

ReToCode commented Jan 10, 2024

Problem description

Kubernetes has a lot of defaulting and validation implemented for its own types, e.g. https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/core/v1/zz_generated.defaults.go#L305 for a container. Knative implements its own defaulting like here. This is useful for stuff where Knative has other defaults or additional values.

This works in most cases, but we loose a lot of defaulting that K8s would do and have to reimplement, e.g. with probes: https://github.com/knative/serving/blob/main/pkg/apis/serving/v1/revision_defaults.go#L157

Also it causes issues like #14771 and we are lacking to default fields that are newly introduced in K8s like StartupProbes.

So it might be good to think about re-using K8s defaulting and validation doing the Knative stuff afterwards.

This is also related to the discussion in: #13204

@ReToCode
Copy link
Member Author

cc @skonto @dprotaso

@ReToCode ReToCode changed the title Improve/adapt Knative defaulting for K8s object types Improve/adapt Knative defaulting and validation for K8s object types Feb 7, 2024
@ReToCode
Copy link
Member Author

ReToCode commented Feb 7, 2024

See also discussion in #14853 (comment)

Copy link

github-actions bot commented May 8, 2024

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 8, 2024
@ReToCode ReToCode added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. triage/accepted Issues which should be fixed (post-triage) and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. triage/accepted Issues which should be fixed (post-triage)
Projects
None yet
Development

No branches or pull requests

1 participant