-
Notifications
You must be signed in to change notification settings - Fork 734
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
Allow predicates to be disabled on a case-by-case basis via annotation. #5284
Conversation
Allow all predicates to be disabled via annotation. Tests for many upgrade scenarios.
run full pr build |
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.
A comma separated list should suffice here for > 1 predicate. I'll get this change into this PR.
👍 I think it would be great to be able to disable more than one replica.
docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc
Show resolved
Hide resolved
docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc
Show resolved
Hide resolved
Co-authored-by: Michael Morello <[email protected]>
Co-authored-by: Michael Morello <[email protected]>
Update documentation per review comments
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 left a few comments but LGTM.
Since we have some documentation here I would maybe request a review from @alaudazzi
docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc
Outdated
Show resolved
Hide resolved
docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc
Show resolved
Hide resolved
Moving annotation constant to be next to others. Adjusting tense of documentation. Caching logic prior to loop instead of calling same method multiple times. Adjusting e2e test to be more simple for testing predicate disabling.
will merge after review by @alaudazzi, as suggested. |
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.
Left a few suggestions in the Asciidoc file, otherwise LGTM.
docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc
Outdated
Show resolved
Hide resolved
docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc
Outdated
Show resolved
Hide resolved
docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc
Outdated
Show resolved
Hide resolved
docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc
Outdated
Show resolved
Hide resolved
…ions/elasticsearch/orchestration.asciidoc Co-authored-by: Arianna Laudazzi <[email protected]>
…sticsearch/orchestration.asciidoc Co-authored-by: Arianna Laudazzi <[email protected]>
…ications/elasticsearch/orchestration.asciidoc Co-authored-by: Arianna Laudazzi <[email protected]>
…elasticsearch/orchestration.asciidoc Co-authored-by: Arianna Laudazzi <[email protected]>
…n. (elastic#5284) * Allow predicates to disabled on a case-by-case basis via annotation. Allow all predicates to be disabled via annotation. Tests for many upgrade scenarios. * Adding documentation for the feature. * Add e2e test allowing cluster upgrade while cluster is red by disabling predicate. * fix annotation spelling Co-authored-by: Michael Morello <[email protected]> * better logging of disabling predicate Co-authored-by: Michael Morello <[email protected]> * Move disabled predicate logic to pkg/apis Update documentation per review comments * Add a predicate check to the CI checks per the review comments. * Adjusting warning in documentation around disabling predicates. Moving annotation constant to be next to others. Adjusting tense of documentation. Caching logic prior to loop instead of calling same method multiple times. Adjusting e2e test to be more simple for testing predicate disabling. * remove unused annotations var * Adjust predicate warning in docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc Co-authored-by: Arianna Laudazzi <[email protected]> * lowercase yellow in docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc Co-authored-by: Arianna Laudazzi <[email protected]> * Adjust predicate explanation in docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc Co-authored-by: Arianna Laudazzi <[email protected]> * Correct misspelling in docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc Co-authored-by: Arianna Laudazzi <[email protected]> Co-authored-by: Michael Morello <[email protected]> Co-authored-by: Arianna Laudazzi <[email protected]>
Closes #2092
This change will allow ECK user to disable certain upgrade predicates, by name, via an annotation on the Elasticsearch CRD, thus allowing clusters to be "forced" to be upgraded in scenarios where the default predicates (that disallow upgrade because of a set of rules) are too restrictive.
Use Case 1:
Cluster is a "red" state because of an un-assignable shard. This cluster would never be allowed to be upgraded with the standard set of upgrade predicates in place.
If the following annotation was added to the cluster
And the version was bumped to
7.15.2
, then this cluster's nodes would be allowed to be upgraded in this scenario, even with the cluster in a "red" state.Use Case 2:
A test Elasticsearch cluster has been setup, and regardless of any state of the cluster, a user wants to force an upgrade.
With the following annotation, and a version bump to
7.15.2
, all predicates will be disabled, allowing an upgrade to proceed regardless of the state of the cluster:Discussion Points
Do we want to allow anything other than disabling one predicate, or disabling all predicates? Such as disabling 2 or more predicates specifically? The way this is designed at the moment, this wouldn't be allowed.. This limit was assumed, as there appeared to be a 256 character limit on the values of annotations, but sincekubectl.kubernetes.io/last-applied-configuration
clearly uses more characters than that, this assumption was wrong. A comma separated list should suffice here for > 1 predicate. I'll get this change into this PR.Todo