Skip to content
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

Merged
merged 23 commits into from
Jan 10, 2024

Conversation

ncapps
Copy link
Contributor

@ncapps ncapps commented Nov 14, 2023

Add generator references per #5352

Additional kustomization references will be updated in subsequent PRs.

@k8s-ci-robot
Copy link
Contributor

This PR has multiple commits, and the default merge method is: merge.
You can request commits to be squashed using the label: tide/merge-method-squash

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.

@k8s-ci-robot
Copy link
Contributor

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@k8s-ci-robot k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Nov 14, 2023
@ncapps
Copy link
Contributor Author

ncapps commented Nov 14, 2023

/label tide/merge-method-squash

@k8s-ci-robot k8s-ci-robot added the tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges. label Nov 14, 2023
Copy link
Contributor

@annasong20 annasong20 left a 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
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Member

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
Copy link
Contributor

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.

Copy link
Contributor Author

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)
Copy link
Contributor

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)

Copy link
Contributor Author

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.

@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Nov 16, 2023
@ncapps ncapps marked this pull request as ready for review November 17, 2023 01:14
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 17, 2023
@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Nov 26, 2023
@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Nov 26, 2023
@annasong20
Copy link
Contributor

/unassign
Sorry @ncapps @stormqueen1990 @natasha41575, I don't think I'll have time to give this PR prompt reviews. Please proceed without me.

@natasha41575
Copy link
Contributor

@stormqueen1990 let me know when you give this one an LGTM and I can take a quick look for a final approval!

Copy link
Member

@stormqueen1990 stormqueen1990 left a 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

Comment on lines +6 to +7
description: >
Generate ConfigMap objects.
Copy link
Member

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.

Copy link
Contributor Author

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

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Dec 11, 2023
@stormqueen1990
Copy link
Member

@natasha41575 LGTM'd!

@ncapps
Copy link
Contributor Author

ncapps commented Dec 13, 2023

This is related to #5379

@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 10, 2024
@k8s-ci-robot k8s-ci-robot merged commit f3fedac into kubernetes-sigs:master Jan 10, 2024
9 checks passed
@ncapps ncapps deleted the docs/ref/kustomization branch January 11, 2024 00:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges.
Projects
Development

Successfully merging this pull request may close these issues.

5 participants