Provide a schema for the Kiali CRD #8237
Comments
|
We should also highly consider moving all settings to camelCase (finally!). Since the schema is going to be changed in potentially major ways, it would also be a perfect time to move to camelCase as well. |
But I think we need to be backward compatible, right? |
Yeah if we changed all the fields from snake_case to camelCase then users would have to migrate their CRs. The easiest transition for users would be for us to bump the CRD version (v1alpha1 --> v1alpha2 or v1 etc.) and provide a conversion webhook that automatically translates the fields for you. But I don't think the ansible operator supports conversion webhooks so if we did that the webhook may need to be written in go and deployed alongside the operator. |
|
I have avoided webhooks like the plague. Don't want to add anything more where things can go wrong for minimal gain. We can release a small CLI utility to convert their CRs if we want. Or we leave snake_case - I'm ok with whatever is easiest. |
What do you want to improve?
Kiali does not provide a structural schema with validation. You can currently create a
KialiCR with invalid fields or fields in the wrong place or fields of the wrong type etc. and there is no validation to give you an error when this happens.Publishing the schema here with the operator helm chart and with the OLM CSV would allow users to have validated Kiali CRs before they are applied. It would also enable you to use tools such as
kubectl explain kialisto help you use the Kiali CR.What is the current behavior?
No Kiali CRD schema.
What is the new behavior?
Kiali CRD schema is published.
The text was updated successfully, but these errors were encountered: