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

Documentation Enhancement for Updating of a Restricted Installation #7703

Open
grant-zietsman opened this issue Apr 8, 2024 · 2 comments
Open
Labels
>docs Documentation

Comments

@grant-zietsman
Copy link

Proposal

Problem

The current Helm installation documentation defines a restricted installation. However, the upgrade documentation doesn't explicitly state how to upgrade a restricted installation.

For example, Upgrading from ECK 2.0 or later only clarifies how the cluster-wide (global) installation should be upgraded.

If you are using Helm.

helm upgrade elastic-operator elastic/eck-operator -n elastic-system

This will update the ECK installation to the latest binary and update the CRDs and other ECK resources in the cluster.

Specifically, it would help to specify the order of upgrading CRDs and the operator. The most obvious assumption seems to be to upgrade CRDs followed by the operator.

This warning also raises uncertainty about what to expect during the intermediate state where the CRDs release is of a newer version than the operator release (compatibility).

Suggestion

  • Clarify how the restricted installation should be upgraded (notably order), especially in light of the version compatibility warning.
  • If this is something that can be easily clarified through external documentation, then perhaps a reference could be added. I recognise that I lack familiarity with CRDs (including distribution and versioning).
@botelastic botelastic bot added the triage label Apr 8, 2024
@pebrc pebrc added the >docs Documentation label Apr 19, 2024
@botelastic botelastic bot removed the triage label Apr 19, 2024
@pebrc
Copy link
Collaborator

pebrc commented Apr 19, 2024

@grant-zietsman we can definetely make some improvements in this area.

Some initial thoughts:

  • CRD should be upgraded first. Main reason is potentiall addition of new API resources that the new version of the operator might rely on. Absence of those API resources types will otherwise leave the operator in crash loop backoff until the CRDs are upgraded
  • for restricted installation the upgrade documentation could be amended to mention that the CRD upgrade needs to be done by a cluster admin while the operator upgrade can be done by any user with sufficient privileges in the target namespace (analoguous to the initial installation)

@grant-zietsman
Copy link
Author

grant-zietsman commented May 2, 2024

@pebrc thanks for your feedback. Both of these points would be a helpful clarification in the documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>docs Documentation
Projects
None yet
Development

No branches or pull requests

2 participants