-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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 generator kustomization references #5447
Add generator kustomization references #5447
Conversation
This PR has multiple commits, and the default merge method is: merge. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Skipping CI for Draft Pull Request. |
/label tide/merge-method-squash |
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.
@ncapps, From a quick glance, I think this looks really good! Commented on some high-level suggestions. Discussion welcome!
@@ -6,3 +6,81 @@ weight: 6 | |||
description: > | |||
Generate ConfigMap resources. | |||
--- | |||
|
|||
## configMapGenerator |
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 think it'll save you time to document the configMapGenerator
field with the built-in ConfigMapGenerator
transformer: https://kubectl.docs.kubernetes.io/references/kustomize/builtins/#_configmapgenerator_. configMapGenerator
uses the built-in ConfigMapGenerator
under the hood and they have essentially the same sub-fields. It'll be much easier for the documentation of one to reference the other instead of repeating ourselves. The built-in transformers are a bit confusing. LMK if you need help understanding.
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 added an API/Generators
section. The ConfigMap and Secret generator types reference the common GeneratorArgs
type. Please let me know if this is what you had in mind.
|
||
--- | ||
|
||
* **apiVersion**: kustomize.config.k8s.io/v1beta1 |
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.
We probably want to move kind: Kustomization
into its own Reference Kustomization file, just so we don't repeat ourselves or overwhelm the reader with multiple contexts. In that file, we can include all the supported fields and point them to the respective field Reference pages, like this one.
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 like this idea! I added a new kustomization.md file.
List of ConfigMaps to generate. | ||
|
||
|
||
### ConfigMapArgs |
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 don't think ConfigMapArgs
is exposed to the user. It is an implementation detail. We might not want to document it, unless it's re-used by secretGenerator
(can't remember off the top of my head, I think it's re-used at least partially). We can potentially document the re-used fields on a separate page.
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 ConfigMap and Secret generators use type.ConfigMapArgs and type.SecretArgs. These types share type.GeneratorArgs though they are different because the secret specifies a type.
Do you have a suggestion for another way to represent this? We could specify a GeneratorArgs
in the common definitions?
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 added GeneratorArgs
to common definitions. Let me know if you are okay with this approach.
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 see these files refer specifically to the kustomization file. configMapArgs
, secretArgs
, and generatorArgs
are all fields that the end user is not expected to have in their kustomization.yaml
. I feel there might be a confusion potential if these are described in this section, but it is useful to have them described in a separate API section for people onboarding to the project as contributors.
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 am definitely open to suggestions for how best to describe the generator arguments. I was attempting to document that Secret and ConfigMap generators share many of the same arguments while avoiding listing the same fields in multiple places.
Using env in the PodSpec as an example, users are not expected to specify an EnvVar
field. It is understood that EnvVar
is a type used to define the fields to include in the env
list.
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 this is using Hugo, we can create a shortcode for including partial pages inside of other pages, similar to what docs.k8s.io currently does:
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.
Thank you for sharing this hugo feature. Though I am not sure this addresses how to document a list of generator arguments. For example, the configMapGenerator
field is a list of the ConfigMapArgs
type. I recognize that users don't specify configMapArgs
anywhere in the Kustomization file, but I believe there should be a way to document what arguments are available for each ConfigMap object in the list.
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.
Please disregard my previous comment. I used your suggestion to create a shortcode to include other markdown and I think the result is improved for the reader. Thank you again for the tip.
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 just checked the rendered preview and it looks nice! 🎉
|
||
Options override global `generatorOptions` field. | ||
|
||
### GeneratorOptions |
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 think GeneratorOptions
is re-used by secretGenerator
, so it can be better referenced on its own page.
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 point. I updated the generatorOptions
page and referenced it from the GeneratorArgs
page.
|
||
Name of the generated ConfigMap. A hash suffix will be added to the Name by default. | ||
|
||
* **namespace** (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.
Probably good to point out optional fields. @koba1t suggested this: #5247 (comment)
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 added an "optional" to the applicable fields. It looks like upstream Kubernetes docs typically notes which fields are required and omits the optional label. I don't feel strongly about either style so long as we are consistent.
450ab5d
to
b5ab6a8
Compare
ef62596
to
c11786b
Compare
c11786b
to
c3dfc06
Compare
/unassign |
@stormqueen1990 let me know when you give this one an LGTM and I can take a quick look for a final approval! |
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 looks good to me as-is. I have some food for thought though that we might want to check whether it'd be possible to use https://github.com/kubernetes-sigs/reference-docs to generate these pages.
/lgtm
description: > | ||
Generate ConfigMap objects. |
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 noticed this description is being rendered on both the parent page and in this page as well. I don't want to hold up this PR on that, but is it fair to create an issue to address it separately?
If we want to copy the behaviour from docs.k8s.io, this description would render solely on the parent page and never in the body of the page that defines 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.
Thanks for catching this! I was curious about how this is configured. I created this issue to remove the description from the body of the page: #5488
@natasha41575 LGTM'd! |
This is related to #5379 |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: natasha41575, ncapps The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Add generator references per #5352
Additional kustomization references will be updated in subsequent PRs.