-
Notifications
You must be signed in to change notification settings - Fork 440
Support overriding CRD type validation for structs #155
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
Comments
I have a similar use case for primitive types, in which I'd like to define an 'enum' as an integer in my Go code, but have it marshal to a JSON string. This is handy because it allows a sane default for the zero type of an enum. For example: // WorkloadState represents the state of a workload.
type WorkloadState int
// MarshalJSON returns a JSON representation of a WorkloadState.
func (s WorkloadState) MarshalJSON() ([]byte, error) {
return json.Marshal(s.String())
}
// UnmarshalJSON returns a WorkloadState from its JSON representation.
func (s *WorkloadState) UnmarshalJSON(b []byte) error {
var ss string
if err := json.Unmarshal(b, &ss); err != nil {
return err
}
switch ss {
case WorkloadStateSynced.String():
*s = WorkloadStateSynced
default:
*s = WorkloadStateUnknown
}
return nil
}
// Workload states.
const (
WorkloadStateUnknown WorkloadState = iota
WorkloadStateSynced
)
// WorkloadStatus represents the status of a workload.
type WorkloadStatus struct {
// ...
State WorkloadState `json:"state"`
} Currently the controller-tools CRD generation code does not appear to support overriding the type detected by reflect. For my use case we could perhaps use the same notation/pattern as openapi-gen's custom type definitions. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
This is still something that would make life easier as a user of controller-tools. FWIW I've also wanted to use this proposed functionality for the original purpose @joelanford mentioned (i.e. storing conditions as a map, but marshalling them to an array) as well as the case I mentioned. |
/remove-lifecycle stale |
This effectively reverts crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value. Signed-off-by: Nic Cope <[email protected]>
This effectively reverts crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value. Signed-off-by: Nic Cope <[email protected]>
This effectively reverts crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value. Signed-off-by: Nic Cope <[email protected]>
This effectively reverts crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value. Signed-off-by: Nic Cope <[email protected]>
This effectively reverts crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value. Signed-off-by: Nic Cope <[email protected]>
This effectively reverts crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value. Signed-off-by: Nic Cope <[email protected]>
This effectively reverts crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value. Signed-off-by: Nic Cope <[email protected]>
This effectively reverts crossplane/crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value. Signed-off-by: Nic Cope <[email protected]>
This effectively reverts crossplane/crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value. Signed-off-by: Nic Cope <[email protected]>
This effectively reverts crossplane/crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value. Signed-off-by: Nic Cope <[email protected]>
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
This was resolved in #200. |
This effectively reverts crossplane/crossplane#325. I still think it would be ideal to represent BindingState as an int with a sane zero value that marshaled to a JSON string, but it is currently impossible to override the type of the field that is used when generating an OpenAPI spec per kubernetes-sigs/controller-tools#155. Until that issue is closed it seems better to simply make this a string with a meaningless zero value.
Currently, it seems the validation type for structs is always assumed to be
object
.controller-tools/pkg/internal/codegen/parse/crd.go
Lines 436 to 441 in 5752ac2
However, structs can be serialized into types other than
object
. Is there a way to override the type detection for structs?I'm trying to do something like the following:
The text was updated successfully, but these errors were encountered: