-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Project file with all user input data #1826
Comments
Hi @estroz, @joelanford, @DirectXMan12, @pwittrock I am pushing it for v3+plugin for we have the chance to discuss it and try to achieve it for the release if we agree on that. Looking for your inputs as well. |
Maybe only hasResource? If you're building a type library you would set
These are already captured in |
Hi @estroz,
Totally agree. Good point.
Currently, the GVK is only persistent on the PROJECT file if the resource is true. So, how the allow all combinations shows that the best way is we store both booleans as use the api one to check if the api was or not scaffolded. See my suggested solution #1849. PS.: I think it will also be beneficial for we address the scenarios raised/discussed in #1772. I hope that you liked it. |
Prior to releasing v3.0.0, the config spec for version
These additions are being made (not intentionally) without considering what they'll look like together, but should be. Perhaps a redesign of version: 3-alpha
resources:
- api: # api contains all important information from `create api`
group: my.domain
version: v1
kind: CronJob
crdVersion: v1
resourceTypes: true # If 'api/v1/cronjob_types.go' was created
controller: true # If 'controllers/cronjob_controller.go' was created
webhook: # webhook contains all important information from `create webhook`
webhookConfigVersion: v1
types:
- validating # If `webhook.Validator` was implemented
- mutating # If `webhook.Defaulter` was implemented
- conversion # If `--conversion` was set The above design groups fields by @Adirio @DirectXMan12 @pwittrock thoughts on making a drastic design change prior to the v3.0.0 stable release? |
My thoughts but written by you. 100% agree. And 100% in favor of omiting as many of these fields as possible if they are default values. |
Each plugin can define its own flags, so would the plugin also control these fields? If so, that kind of points to these fields being stored under the plugin configuration somewhere, possibly. Either way, I feel like this is a pretty major change right as we're trying to stabilize v3. I would vote we hold this out of v3 and make it a candidate for v4. |
Yes. These fields are intended to be general enough such that any plugin can make use of them. If they aren't used by a plugin, then they're omitted from the config, so the user will never have to worry about them.
I am worried about that. Perhaps we should punt on this issue, #1696, and #1849 for now and go with what exists in the current spec, since none of the fields mentioned in this issue or those PRs are necessary for v3.0.0 features. |
Thank you for your contribution. I do NOT agree with them because controllers are NOT APIs and what is suggested here is out of the scope of this issue. Also, see that the proposals here are ONLY to start to track the missing info and NOT change the PROJECT model design at all. I totally agree with @joelanford that we should NOT redesign the PROJECT file for v3. However, folks feel free to raise new issues with your ideas with its purpose to be addressed for v4 plugin. Why we should get merged the (Webhooks data: PR: #1696 and resource/controller=[true|false] #1849) as it is shaped so far for v3?
|
Currently, we have the following model: domain: testproject.org
layout: go.kubebuilder.io/v3-alpha
multigroup: true
projectName: project-v3-multigroup
repo: sigs.k8s.io/kubebuilder/testdata/project-v3-multigroup
resources:
- crdVersion: v1
group: crew
kind: Captain
version: v1
webhookVersion: v1 After we merge the PRs #1696 and #1849 we will have the model: domain: testproject.org
layout: go.kubebuilder.io/v3-alpha
multigroup: true
projectName: project-v3-multigroup
repo: sigs.k8s.io/kubebuilder/testdata/project-v3-multigroup
resources:
- crdVersion: v1
group: crew
kind: Captain
version: v1
webhookVersion: v1
api:true // is true when a GKV has an API scaffolded
controller:false // is true when a GKV has an controller scaffolded
webhooks: // respresents the webhooks
defaulting: true
validation: true Why I do not agree with the suggestions made #1826 (comment)? Regards the suggestion made in #1826 (comment): It shows very closely as it is now.
Suggestion/Question So, besides I still believing that re-design the PROJECT file is out of the scope of this issue, if we still looking for doing this changes here and if my and if my above comments did not help us to reach a consensus already then, WDYT about tries to list what should change and why? It might be helpful to add use cases to illustrate it as what are the problems faced with the current or suggested changes in the model. |
I wouldn't use subcommand names either. Subcommands are based on the most common workflows followed by projects. The most commong thing is to scaffold both the resource type and its controller and that is why they are grouped. Webhooks are less common so they are provided as a separate subcommand. However I do think we need to group and structure this field better. Previously, the project file just stored GVK (Group-Version-Kind). Having two object that represent a resource for the config file ( I think that another issue here is that each of us is calling API to a different thing. You are calling API to whatever gets scaffolded when you do |
To make it easier I centralized all changes in the same PR: https://github.com/kubernetes-sigs/kubebuilder/pull/1696/files. Also, I addressed all suggestions that shows that we 3 can reach a consensus: componentConfig: true
domain: testproject.org
layout: go.kubebuilder.io/v3-alpha
projectName: project-v3-config
repo: sigs.k8s.io/kubebuilder/testdata/project-v3-config
resources:
- api:
namespaced: true
crdVersion: v1
controller: true
group: crew
kind: Captain
version: v1
webhooks:
apiVersion: v1
defaulting: true
validation: true |
Description
Ensure that we are storing all input data in the PROJECT file.
Motivation
I am maintainer like to ensure that we have stored all input data used to scaffold the projects by the user so that I could propose a subcommand/plugin to help users migrate from a plugin version X to X+1 since would be possible scaffold the project from the scratch. Also, it might be helpful in many scenarios to tooling the scaffolds.
Mor info: See: #1644 (comment)
What is missing to be stored
/kind feature
The text was updated successfully, but these errors were encountered: