-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add categories to GG CRDs #5006
Conversation
Issues linked to changelog: |
@@ -13,6 +13,7 @@ spec: | |||
names: | |||
categories: | |||
- gloo-gateway |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want to remove gloo-gateway
from existing crds so we don't have 3 different possible categories?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Decided in standup to replace "k8sgateway" with "gloo-gateway". I added more context as a comment on the issue.
This reverts commit fb383e3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@@ -8,6 +8,9 @@ metadata: | |||
spec: | |||
group: graphql.gloo.solo.io | |||
names: | |||
categories: | |||
- solo-io |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If our approach is that any enterprise CRDs will have solo-io as well, can we clarify that somewhere as an intentional decision? I can see a new CR be added, and it being challenging for a new developer to understand that expectation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully the new README helps? Other suggestions of where to surface that info?
I'm also hopeful that if the new helm test fails, the test code will help devs realize the expectation, but someone may add an enterprise CRD without the solo-io category and the test wouldn't catch that.
enterpriseCRDCategory = "solo-io" | ||
CommonCRDCategory = "gloo-gateway" | ||
|
||
enterpriseCRDs = []string{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: It could be useful to callout that we have other CRDs that have a mix of APIs (some open source, some enterprise) and that we don't consider those "enterprise CRDs" since they contain open source functionality
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new README hopefully clarifies a bit, but not sure where you want this called out and if that's the right place.
@@ -18,4 +18,13 @@ var ( | |||
}, | |||
}, | |||
} | |||
|
|||
enterpriseCRDCategory = "solo-io" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: It almost feels like these are a contract of our product, and deserve to live in our codebase, and then imported into our tests. It would also address my concern about enterprise crds expecting a solo-io category as being challenging for a new dev to discover
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tbh I was a little surprised there wasn't already a list of the enterprise CRDs elsewhere in the code base, but I didn't find one. Any suggestions for where/in what format this ought to live?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a list in enterprise here. i don't know if it makes sense to add any more enterprise-specific code in our OSS repo (although the enterprise crds live in the oss repo so it's a little messy to begin with). maybe it makes sense to add these new enterprise-specific tests in solo-projects only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm obviously biased by the additional effort of moving the tests 🙃 but I would prefer to keep the tests closer to the code changes. I'd rather see the tests fail in this repo when I add a new CRD with the wrong categories than have someone else notice a failure in solo-projects some unknown time after my gloo PR has merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work!
/kick |
@@ -81,7 +82,7 @@ func (s *testingSuite) TestApplyCRDs() { | |||
if err != nil { | |||
return err | |||
} | |||
if info.IsDir() { | |||
if info.IsDir() || info.Name() == "README.md" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah i didn't realize the readme was added in the crds
dir. i'd suggest either moving it elsewhere (if there's a good place to put it), or adding the README.md to the helmignore file so it doesn't get packaged with our helm chart
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha. I was surprised codegen passed but figured it was fine if so.
I think adding it to the helmignore file is the right call, but it won't fix the test which pulls from the install/helm directory directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like a good start, but leaves us open to future files causing the same issue. What if instead, we examine the file extension, and if it's yaml we assume it's a CRD, and if it's not we skip it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I almost did that but I'm kinda okay with this being more strict to remind us to be thoughtful adding things to that folder? Maybe it'll prompt someone to suggest adding it to the .helmignore
for instance :)
Description
Add common and enterprise categories to Gloo Gateway CRDs so that the convenient
kubectl get gloo-gateway -A
can be used to list all GG CRs on the cluster, andkubectl get solo-io -A
can be used to list all GG enterprise CRs.API changes
Added category/ies to CRDs
Interesting decisions
This PR follows the example of #5592, which shows that solo-kit only generates the schema section of the CRD (see #5592 (comment)). Therefore, we hardcode the new categories in the CRD yaml files.
Testing steps
I manually verified behavior by generating the helm chart and applying it, applying CRs, and running
kubectl get solo-io
, just as the e2e test does.Notes for reviewers
I'd like feedback on whether the
KubeGatewaySuite
is the appropriate suite for the new e2e tests.Checklist: