Update 8.0 breaking change template to gather information on how to programmatically detect it #82905
Conversation
…rogrammatically detect it.
cjcenizal
added
v8.0.0
release_note:skip
| @@ -30,6 +30,8 @@ requesting the breaking change to be surfaced in the Upgrade Assistant. | |||
| <!-- e.g. Based on telemetry data, roughly 75% of our users will need to make changes to x. --> | |||
| <!-- e.g. A majority of users will need to make changes to x. --> | |||
|
|
|||
| **How can we programmatically determine whether the cluster is affected by this breaking change?** | |||
There was a problem hiding this comment.
Were you just looking for the pseudo-code? Is my understanding correct that this isn't just for KIbana-specific deprecations?
There was a problem hiding this comment.
Were you just looking for the pseudo-code?
Pseudo-code is an option if that's the best way to communicate how this will be done, or it could just be a plain-speech description of what APIs, settings, entities, etc need to be examined and how they'd be accessed. Does that make sense? Should I clarify this in the template?
Is my understanding correct that this isn't just for KIbana-specific deprecations?
Correct, this is for any deprecation of any component of the Stack. So when I refer to "cluster" I guess I'm really referring to the cluster and any client that interacts with it. Is that what spurred your question?
There was a problem hiding this comment.
I was trying to think through what this section would look like for the different products. This is compounded by the current ambiguity between which deprecations will be surfaced by the "Deprecation Info API" vs the "Deprecation logs".
For Elasticsearch deprecations, we won't need any code written in Kibana to detect whether or not a deprecation is currently being violated, Kibana will just be consuming ES's deprecation info API and deprecation logs to make this determination.
For Kibana deprecations, we haven't exposed any core APIs to implement the equivalent of the deprecation info API , or the deprecation logs, but assuming we do, we will require the team that is responsible for the deprecation to write the code to detect it.
And for the other products, we're in a similar position where Kibana needs to consume either their deprecation Info APIs, or their deprecation logs.
So it's not immediately obvious to me why we'd be making the author of the GitHub issue fill out this section.
There was a problem hiding this comment.
Got it! In many cases people are already providing details on how you'd determine if the breaking change is in effect. For example, #82578 notes that you'd check the xpack.security.audit.enabled setting. However, this info is mixed in with the "What can users do to address the change manually?" section. By separating it out, I'm hoping to make it easier to categorize the different ways people can check for the presence of the breaking change, which will affect design and implementation. I think this will also make it easier to tell that we're a missing component like a Kibana deprecation info API.
There was a problem hiding this comment.
Fair enough. I agree that it helps with the Kibana-specific deprecations.
* master: (39 commits) Fix ilm navigation (elastic#81664) [Lens] Distinct icons for XY and pie chart value labels toolbar (elastic#82927) [data.search.aggs] Throw an error when trying to create an agg type that doesn't exist. (elastic#81509) Index patterns api - load field list on server (elastic#82629) New events resolver (elastic#82170) [App Search] Misc naming tech debt (elastic#82770) load empty_kibana in test to have clean starting point (elastic#82772) Remove data <--> expressions circular dependencies. (elastic#82685) Update 8.0 breaking change template to gather information on how to programmatically detect it. (elastic#82905) Add alerting as codeowners to related documentation folder (elastic#82777) Add captions to user and space grid pages (elastic#82713) add alternate path for x-pack/Cloud test for Lens (elastic#82634) Uses asCurrentUser in getClusterUuid (elastic#82908) [Alerting][Connectors] Add new executor subaction to get 3rd party case fields (elastic#82519) Fix test import objects (elastic#82767) [ML] Add option for anomaly charts for metric detector should plot min, mean or max as appropriate (elastic#81662) Update alert type selection layout to rows instead of grid (elastic#73665) Prevent Kerberos and PKI providers from initiating a new session for unauthenticated XHR/API requests. (elastic#82817) Update grunt and related packages (elastic#79327) Allow the repository to search across all namespaces (elastic#82863) ...
No description provided.