-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
docs: Include ref to addon naming and config documentation #3043
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
docs: Include ref to addon naming and config documentation #3043
Conversation
I'm curious to know more about why you think this will be helpful to users - specifically, is a doc comment within the source code is providing the necessary value? Conversely, as a user - how am I thinking about finding this information - am I doing a google search or ? |
Great question. The ultimate aim in my view is to provide the precise names of the addons to be included in the map. In my experience, when first starting to fiddle with addons it's not immediately apparent what the specific map key should be (e.g. The line comment on the resource itself was the simplest way I could think to inject the relevant doc into the code base. The challenge with that particular doc is that the actual information (the names of the addons) is embedded in dropdown menus for each addon, so it takes a bit of extra digging to get to the salient info. It's also not apparent from reading that doc that the AWS name mentioned there will be the exact same name that the Terraform ingests (it takes some cross referencing of the existing examples). Granted, this is all of relatively minor concern but including a ref might be a helpful reassurance that the information is contained in the page and translates to the name they should use. That being said, I'm also more than happy to put in some more robust documentation or examples that obviate the need to seek out external resources to begin with. I'm thinking a brief explanation with an example body along the lines of:
If that's of interest to the community I could put together an |
I think for these things, the best source of truth is the API -
|
Makes sense. I've refactored it to add this info as an entry to the FAQ. Personally I feel like this would have been helpful info when I was first getting started but if it is deemed to be redundant or of limited value then feel free to close out this PR. I also removed a reference to deploying Windows nodes in the FAQ which as far as I could tell did not have a corresponding entry. |
This PR is included in version 20.12.0 🎉 |
is |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Description
Includes a reference to AWS documentation for EKS Cluster addon names and configuration details.
I'm happy to write a more in-depth description with examples but I wasn't sure of the best place to do so, so I went with the simplest solution. Feel free to let me know if there's a more reasonable place for this to live.
Motivation and Context
Assists operators in more easily discerning the precise addon names to include in their modules.
Closes #3008
Breaking Changes
No
How Has This Been Tested?
examples/*
to demonstrate and validate my change(s)examples/*
projectspre-commit run -a
on my pull request