[ML] Adding a known issue for the ML datafeed auth header problem#92274
Merged
droberts195 merged 4 commits intoelastic:mainfrom Dec 13, 2022
Merged
[ML] Adding a known issue for the ML datafeed auth header problem#92274droberts195 merged 4 commits intoelastic:mainfrom
droberts195 merged 4 commits intoelastic:mainfrom
Conversation
Due to elastic#41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to elastic#87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
Contributor
|
Documentation preview: |
Collaborator
|
Pinging @elastic/ml-core (Team:ML) |
Collaborator
|
Pinging @elastic/es-docs (Team:Docs) |
szabosteve
approved these changes
Dec 12, 2022
Contributor
szabosteve
left a comment
There was a problem hiding this comment.
Left a few suggestions, mostly just for reducing the word count. Please take or leave them. Otherwise, LGTM. Thanks for documenting this issue.
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
…into ml_dfeed_auth_known_issue
Collaborator
💔 Backport failed
You can use sqren/backport to manually backport by running |
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Dec 13, 2022
…astic#92274) Due to elastic#41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to elastic#87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Dec 13, 2022
…2274) (#92318) Due to #41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to #87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by #92168 and fixed by #92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Dec 13, 2022
Due to elastic#41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to elastic#87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive. Backport of elastic#92274
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Dec 13, 2022
Due to elastic#41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to elastic#87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive. Backport of elastic#92274
elasticsearchmachine
pushed a commit
that referenced
this pull request
Dec 13, 2022
…em (#92323) Due to #41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to #87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by #92168 and fixed by #92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive. Backport of #92274
droberts195
added a commit
that referenced
this pull request
Dec 13, 2022
…em (#92324) Due to #41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to #87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by #92168 and fixed by #92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive. Backport of #92274
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Due to #41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency.
Due to #87884 datafeeds with authorization headers older than 7.0 prevent all datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI.
The problem is alleviated by #92168 and fixed by #92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive.