-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
Open API 3 Schema #9
Comments
also possible alternative: simpler API, less functionality (in a good way), less dependencies. |
Ive been bike shedding on this one a bit. Kube 1.13+ will do the validation for the custom resource on creation, so I'm not positive if we'd even need a library. Ive been wondering if its worth while to add validation into the lifecycle and for <1.13. I was kinda rolling this up with the prereq for #10, but we could get away with just enough logic to reflect on the OAI spec enough that its possible to generate a YAML resource template 🤷♂️ |
sounds great, all for offloading responsibility. 👍 we can always pick this up when this becomes a pain point |
a bit offtopic: we should have labels with prios / or difficulty levels :) |
Started adding some labels! |
FWIW, lacking CRD validation/definition is the only thing that has made Elixir/Bonny a much harder sell for operator development than the operator sdk. For me personally it's worth giving that up to get to use such a pleasant framework, but it would be really great to have. |
Do I get this wrong or what is really missing is bonny generating CRD of apiVersion CRD v1 documentation: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ in other words (i.e. brainstorming more): How do we define the schema of the CRD in the controller? If I'd have to write a ton of module constants, I'd rather just write the yaml directly... hence the idea of somehow leveraging typespecs... |
Yeah great thoughts mruoss. I'm planning to fix #117 in a bit because v1beta1 is now removed from k8s so it's a matter of time until it starts breaking. (and for me I can't even get off the ground because we're on k8s 1.21). I'll definitely put some thought into this as well while I'm at it. I may even do an experiment and see how it feels. |
Alright, with #143 we now generate a valid I guess we need to be able to define the whole schema as a plain map in the controller somewhere. OR - I'm still a fan of alternatively letting the user define the CRD YAML first and let the controller use that to create the watcher/reconciler streams. |
Contract first approach is good but it transfers the yaml creation to the user and not all users may have complete mastery of the correct format. We should add good documentation and examples for those who don't know how to set their types to the correct pattern |
Thanks for chipping in! Is it really the case that "users" who write operators don't have mastery of the CRD YAML? In any case they are gonna have to have complete mastery of the OpenAPI V3 schema if they want to declare it. Because there's no taking that away it seems. Another idea I had (very off topic): The manifest generator could send each resource (deployment, roles, service account, crds) to a user defined callback where the user could pattern match and modify the resulting structure (e.g. add labels, annotations, OR an OpenAPI schema,...) |
I totally agree, I just think we should be careful to educate users through good examples.
About the second case of the yaml generator I agree that the user needs to be able to add things like resources, health checks, annotations and any other things that can be customizable |
Not sure if validation itself should be a part of Bonny since kubernetes >1.13 will validate the HTTP operation.
We should support generating the Open API as a part of the CRD though. This will help with
kubectl explain my-resource
, enable validation at the kube API, and allow use to generate resource manifests #10It could be very similar to how phoenix generates models:
Open API 3 Schema Validation
Elixir Library
Include schema in #26
The text was updated successfully, but these errors were encountered: