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
+kubebuilder:default={} does not use nested defaults #622
Comments
We need to initialize `ovnKubernetesConfig.policyAuditConfig` so that the proper defaults are populated when a CNO config object is created It would be better to do this using the `+kubebuilder:default` flag however it is broken for this case as described in this [upstream issue](kubernetes-sigs/controller-tools#622) Signed-off-by: astoycos <astoycos@redhat.com> TMP
We need to initialize `ovnKubernetesConfig.policyAuditConfig` so that the proper defaults are populated when a CNO config object is created It would be better to do this using the `+kubebuilder:default` flag however it is broken for this case as described in this [upstream issue](kubernetes-sigs/controller-tools#622) Signed-off-by: astoycos <astoycos@redhat.com> TMP
We need to initialize `ovnKubernetesConfig.policyAuditConfig` so that the proper defaults are populated when a CNO config object is created It would be better to do this using the `+kubebuilder:default` flag however it is broken for this case as described in this [upstream issue](kubernetes-sigs/controller-tools#622) Signed-off-by: astoycos <astoycos@redhat.com>
We need to initialize `ovnKubernetesConfig.policyAuditConfig` so that the proper defaults are populated when a CNO config object is created It would be better to do this using the `+kubebuilder:default` flag however it is broken for this case as described in this [upstream issue](kubernetes-sigs/controller-tools#622) Signed-off-by: astoycos <astoycos@redhat.com>
We need to initialize `ovnKubernetesConfig.policyAuditConfig` so that the proper defaults are populated when a CNO config object is created It would be better to do this using the `+kubebuilder:default` flag however it is broken for this case as described in this [upstream issue](kubernetes-sigs/controller-tools#622) Signed-off-by: astoycos <astoycos@redhat.com>
We need to initialize `ovnKubernetesConfig.policyAuditConfig` so that the proper defaults are populated when a CNO config object is created It would be better to do this using the `+kubebuilder:default` flag however it is broken for this case as described in this [upstream issue](kubernetes-sigs/controller-tools#622) Signed-off-by: astoycos <astoycos@redhat.com>
We need to initialize `ovnKubernetesConfig.policyAuditConfig` so that the proper defaults are populated when a CNO config object is created It would be better to do this using the `+kubebuilder:default` flag however it is broken for this case as described in this [upstream issue](kubernetes-sigs/controller-tools#622) Signed-off-by: astoycos <astoycos@redhat.com>
We need to initialize `ovnKubernetesConfig.policyAuditConfig` so that the proper defaults are populated when a CNO config object is created It would be better to do this using the `+kubebuilder:default` flag however it is broken for this case as described in this [upstream issue](kubernetes-sigs/controller-tools#622) Signed-off-by: astoycos <astoycos@redhat.com>
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen |
@astoycos: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/bug |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen |
@therealak12: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen |
@astoycos: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This issue seems not fixed? |
- Unify pointer and omitempty JSON tag usage - Add all default fields for struct with default values. With the exception of HZ anc MC spec. The change is done due to the issue in kubernetes-sigs/controller-tools#622 - WanReplication Queue , Batch and Acknowledgment fields did not have struct default values but they were not pointers so those fields acted like they had default values. Added explicit struct default values. - Add enum kubebuilder tags - Add optional comment for forgotten fields - Add explicit required comment for required field
- Unify pointer and omitempty JSON tag usage - Add all default fields for struct with default values. With the exception of HZ anc MC spec. The change is done due to the issue in kubernetes-sigs/controller-tools#622 - WanReplication Queue , Batch and Acknowledgment fields did not have struct default values but they were not pointers so those fields acted like they had default values. Added explicit struct default values. - Add enum kubebuilder tags - Add optional comment for forgotten fields - Add explicit required comment for required field
- Unify pointer and omitempty JSON tag usage - Add all default fields for struct with default values. With the exception of HZ anc MC spec. The change is done due to the issue in kubernetes-sigs/controller-tools#622 - WanReplication Queue , Batch and Acknowledgment fields did not have struct default values but they were not pointers so those fields acted like they had default values. Added explicit struct default values. - Add enum kubebuilder tags - Add optional comment for forgotten fields - Add explicit required comment for required field
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This is still an issue. What "works" as a sort of workaround is specifying the default verbatim in every
which is error prone and counterproductive. Field based defaults should be enough. /reopen |
@pmalek: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen |
@astoycos: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/remove-lifecycle rotten |
This issue has been here for over two years now 😵 Does anyone plan to work on it? |
I just experienced the same behavior. I've used #622 (comment) as a workaround. |
This change adds: - a test to validate that the sf-operator can reconsile a SF CR with the minimal set of settings. - a fix to provide default value for the logserver if the main field is not set. - a fix for the system-config pipeline generator where the zuul connection name for the config repo is never recomputed. See: kubernetes-sigs/controller-tools#622 Change-Id: Ibce761d80a9d90eeef29c09105b569890f1b4d8e
/lifecycle frozen |
Not sure if I got this correctly. I think in your example the default of Here another example: // +kubebuilder:default={}
// +optional
ControlPlaneCertificateRotation *ControlPlaneCertificateRotation `json:"controlPlaneCertificateRotation,omitempty"`
type ControlPlaneCertificateRotation struct {
// +kubebuilder:default=true
// +optional
Activate bool `json:"activate"`
// +kubebuilder:default=90
// +kubebuilder:validation:Minimum=7
// +optional
DaysBefore int32 `json:"daysBefore"`
} This results in: default: {}
properties:
activate:
default: true
type: boolean
daysBefore:
default: 90
format: int32
minimum: 7
type: integer
type: object The result is at runtime that Kubernetes will first default the controlPlaneCertificateRotation field to an empty object and then default each individual field (defaulting happens top-down and nested defaults are only applied if the parent exists) |
So I believe I exposed a bug in kubebuilder...
when I define a +kubebuilder:default={} as a pointer to another type with +kubebuilder:default values I assume those values should propagate to the parent object.
For example
Where the PolicyAuditConfig is defined in the same package
However rather than rendering the default correctly I see the following in the generated yaml
Specifically the default value is
null
where it should be populated automatically by the defined nested defaults.I am happy to help propose a fix here, however after spending some time playing with the codebase I'm realizing I will probably need some assistance from someone more experienced with kubebuilder
I already reached out on slack and got no response, which prompted me to open this issue.
Thanks,
Andrew
The text was updated successfully, but these errors were encountered: