-
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
[Discussion] V3 breaking changes #1772
Comments
IMO: Over split the command create api
So, shows for me that we might be prevailing keep it ease to maintaining instead of user experience. In this way, I am afraid that I am more inclined to vote against since I think the UX is more important here. Over new flag to work with external types I totally agree that we need to address this scenario. WDYT about we raise a new specific issue for this RFE? Also, instead of not scaffold the files I think we ought to educate and facilitate to the users how to work with for the external type which could be something such as we have a new plugin for that since we will not create an api but we will add one preexistent into the project. Example:
import (
...
routev1 "github.com/openshift/api/route/v1" // see {{kindversion}} {{module}}
...
)
...
func init() {
...
// Add external type
utilruntime.Must(routev1.AddToScheme(scheme))
import (
...
routev1 "github.com/openshift/api/route/v1" // see {{kindversion}} {{module}}
...
)
....
var _ = BeforeSuite(func(done Done) {
...
err = routev1.AddToScheme(scheme.Scheme) // see {{kindversion}}
Expect(err).NotTo(HaveOccurred())
...
} |
|
+1000 for @estroz suggestions 🥇 :
I liked the following as well to be scaffolded in the go.mod
I just would like to clarifies that I do not think that we should add that to the |
We should probably define the API from a design point of view, chosing what are commands, what are arguments and what are flags, and from the arguments and flags, which are required, which have a default value, and which will ask the user for input if he didnt specify it. |
Shows that we could create an EP for the add api option. WDYT? |
Any template for the EP? |
I'd suggest you try to add further details and maybe follow up a little bit the template https://github.com/operator-framework/enhancements/blob/master/enhancements/template.md might be helpful for you achieve it. |
Discussion related to this has taken place in another Issue. @estroz (#1826 (comment)) suggested re-designing the project configuration file in order to provide a better structure as the current one has received several patches over time and is a bit unclear.
I also suggested a new design (#1826 (comment))
@camilamacedo86 and @joelanford said that they would push this re-design to |
Following my concerns with the proposed design:
So, before we discuss the changes I think that would be important we list what are the problems with the current project file design that we are trying to solve that justify these changes. WDYT? Could we list that here? |
We have this scheduled for thursday, but just some quick notes:
As you said, we need to allow it. The model I provided sets a default version for each but the individual resources can modify it. This way we reduce verbosity when all or most of the resources use one version.
I do agree that API is not a good term, and I asked for suggestions for how to call a CRD + controllers + webhook. But, currently, we are calling API to CRD + controller ( |
Hi @Adirio,
The suggestion made does not allow we have diff versions of api for crds and webhooks in the same project. So, we cannot:
By following the thread #1644 (comment) you will find all reasons and use cases. See that it is : 1 GKV can have a 1 CRD which can have 1 crdVersion The model needs to be legitim to what they represent (DDD concept) what will be or not an allowed because of the business rules should not change it. In this way, I do not agree that it would reduce verbosity. It would not allow the tool to do the scaffolds as it can be done and introduce limitations that can result in breaking changes in the future.
The command |
@camilamacedo86 The provided model does support different versions. See how in
I added comments in places where some fields could be added to override the defaults and specify which the defaults would be. About the API point: I updated the diagram to swap the slice of strings for the pointer to a struct for webhook types and a couple of other cosmetic changes: An alternative would be making
|
Hi @Adirio, Following my considerations regards the suggestions made. Regards: version: 3-alpha
domain: my-domain.com
crdVersion: v1beta1
webhookVersion: v1beta1
And then, the same is possible for webhook. So, we cannot add the Regards: resources:
- group: Ships
# version omitted means v1 It makes no sense for me since the GVK can assume any possible string value. Has no default value for the version of the GKV. Regards: # path omitted means it is not an external type
....
definition:
# external ommited means false I am ok with we add attrs related to the external types 👍 if they are required, but it should be part of the scope and code implementation of the EP to add helpers to allow users works with. Try to define it before we have the feature shows put the cart before the horse ( Regards definition:
# external ommited means false
# version omitted means v1beta1 (see line 3)
namespaced: true This attr is ONLY relevant when we scaffold API"s for the project. I agree that we could track that but then, it shows part of the api structure domain of responsibility. The resources:
- api:
namespaced: true
crdVersion: v1
controller: true Regards: webhooks:
# version omitted means v1beta1 (see line 4)
types:
- validating In the PR #1696 we have now: webhooks: // respresents the webhooks
apiVersion: v1
defaulting: true
validation: true I am not in favour of the suggestion because:
|
These fields can be also specified per resource. They are just defining a project-wide default. This is just an optimization (and could be added later as it would be non-breaking). Imagine that we are working with an old kuebernetes version a we want all our crd versions to be
Again, defaulting to
All the discussion is because we are adding fields that we are not using yet but plan to use in a future. Why do you think adding this is a premature optimization but adding
Okey, just replace
Sorry that was a typo, I meant: webhooks:
# version omitted means v1beta1 (see line 4)
types:
validating: true |
Now that we are working on
v3
, it may be time to go ahead and do some of this changes that we can't do on an stable version (such asv2
). This issue is meant to be a discussion to see which of them shows enough interest by the developers/community in order to implement them.v1
andv2
,kubebuilder create api
crteates both the CRD and the controller. Do we still think this is the desired behavior? Should we have a separate subcommand for the controller and eliminate the--resource
and--controller
flags? Should these two subcommands replace the current one or should we have three (create resource
for the resource only,create controller
for the controller only,create api
for both of them)?If you think there are other related topics we should discuss, comment and I will add them here.
/cc @droot @DirectXMan12 @mengqiy @pwittrock @camilamacedo86 @estroz @joelanford
The text was updated successfully, but these errors were encountered: