-
Notifications
You must be signed in to change notification settings - Fork 195
Elastic Stack Helm chart upgrade and configuration changes documentation #4388
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
base: main
Are you sure you want to change the base?
Conversation
Vale Linting ResultsSummary: 1 suggestion found 💡 Suggestions (1)
|
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.
although I don't know too much about kubernetes / helm, none of this struck me as superfluous information. I think you did a good job of adding the right amount of info but keeping it task-based for the ECK context.
approving because this is nearly perfect - whatever you do from here is mergeable from my pov.
one thing that might be missing: do I need a specific version of the helm chart to access later versions of the stack? e.g. is upgrading the helm chart version a prerequisite? If that is the case, I believe it is not clear.
deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md
Outdated
Show resolved
Hide resolved
deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md
Outdated
Show resolved
Hide resolved
deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md
Outdated
Show resolved
Hide resolved
deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md
Outdated
Show resolved
Hide resolved
deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md
Outdated
Show resolved
Hide resolved
deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md
Outdated
Show resolved
Hide resolved
deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md
Outdated
Show resolved
Hide resolved
deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md
Outdated
Show resolved
Hide resolved
deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md
Outdated
Show resolved
Hide resolved
| ::::{note} | ||
| If you deploy your {{stack}} resources using our Helm chart, refer to [](/deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md#k8s-upgrade-modify-helm) for details on how to perform upgrades with Helm. | ||
| :::: |
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 note kind of works, but I don't like how it's splitting the instructions and example, and it is burying an up-front choice in the middle of the procedure
consider instead:
- introducing that there are two ways to do it in the intro for the page
- making two H2s, one for each: e.g. "Perform the upgrade in the cluster spec file" "Perform the upgrade using a Helm chart"
not sure if there is a better way to word the headings, because it's less about the method of performing the upgrade, than the context of the configuration ... some alternative headings might be:
"For orchestrators using spec files"
"For orchestrators using Helm charts"
orchestrators / operators / environments / deployments / clusters ... whatever feels the most accurate
you see what I'm getting at :)
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 your point, and I agree.... however I didn't want to do extra changes on documents that are already established and feel very simple (in a good way).
Take in mind the following and let me know your thoughts.... :)
Currently we have this:
-
The doc intro feels accurate for all ECK users (helm vs no helm) as it starts with an intro about upgrading in general with links to preparations, etc.
-
Then when it comes to the "procedure" what we show is that technically upgrading is super simple, just change the
versionof your spec. It's true that we don't mention helm based installations earlier, but considering how small the procedure is and that we have the note right after I think it should be fine. -
I also think it's good to "force" a helm-user to read the standard procedure, because at the end of the day, what they have to achieve through helm is the same (change the
versionon the final spec file).
What I think we could really to do improve this is moving upwards these two paragraphs that are currently at the end:

They are relevant to all users and those feel a big hidden at the end of a big example. Maybe those 2 paragraphs could be in the intro. What do you think? :)
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 moving up those paragraphs makes sense, but I still think that forcing helm chart users to read through this procedure is a little confusing, especially because the easiest way to upgrade is via a flag on a helm command, which might impact the underlying spec file, but it's not the same thing as editing the spec file directly.
won't block this but that is my opinion
Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
This PR adds documentation for Elastic Stack Helm chart (provided by ECK) users to know how to upgrade and apply configuration changes.
As you'll see, certain parts of the content are not purely about ECK and Elastic Stack specifics, but a bit about how Helm works and educates the reader in areas that are not purely ours.
I've tried to fit the content to our exact domain, but giving enough information to understand the basics.
Closes #3591
After admin-docs review we will need to find devs to review the content.