rudr
rudr copied to clipboard
oam-dev
Implement schema on CRD definition
Hopefully, we should be able to just drop in a subset of the schema from the spec. Reference: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema
This doesn't require a lot of specialized Rudr knowledge, and a suitable starting schema can be found here: https://github.com/oam-dev/spec/tree/master/schema
I'm glad to assign you.
Hopefully can make contribution to this project. XD
@fengzixu Hi, are you still working on this? Feel free to tell us if there are any problems.
Yep. I have been working on this issue. Sorry for reply this late. Actually, for this issue, the task I need to do is revising the logic of rudr to adapt the newest schema in https://github.com/oam-dev/spec/tree/master/schema. Am I right? @wonderflow
@wonderflow Hi. After I checked the rudr code component.rs in the schematic directory, I found all fields in https://github.com/oam-dev/spec/tree/master/schema have been implemented. Is there any work need to do for component schema?
You could help check if the jsonschema is out of date and make it consistent with the latest spec.
Then just put the jsonschema into the chart of rudr using OpenAPI v3.0 validation schema
I checked all crd files in https://github.com/oam-dev/rudr/blob/master/charts/rudr/crds directory. All apiVersion is apiextensions.k8s.io/v1beta1.
According to the doc:
Validation of custom objects is possible via OpenAPI v3 schemas or validatingadmissionwebhook. In apiextensions.k8s.io/v1 schemas are required, in apiextensions.k8s.io/v1beta1 they are optional.
Should we change apiVersion to apiextensions.k8s.io/v1 firstly?
Now we still support k8s v1.15, so we should keep it as apiextensions.k8s.io/v1beta1. I think add openAPI V3 validation schema into the CRD won't conflict with the API version.
Did you find any issue with it? If so, feel free to open a new issue. @fengzixu
You could help check if the jsonschema is out of date and make it consistent with the latest spec.
Then just put the jsonschema into the chart of rudr using OpenAPI v3.0 validation schema
You mean the spec content in jsonschema of spec repository may is expired. But the spec content in rudr repository is the newest. Am I right? @wonderflow
Based on my understanding, I just need to transform all necessary fields from spec/schema to the rudr/crds according to the rule https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#validation. @wonderflow