Skip to content

Update 8.0 breaking change template to gather information on how to programmatically detect it #82905

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Nov 9, 2020
Merged

Update 8.0 breaking change template to gather information on how to programmatically detect it #82905

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions .github/ISSUE_TEMPLATE/v8_breaking_change.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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?**
Copy link
Contributor

@kobelb kobelb Nov 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were you just looking for the pseudo-code? Is my understanding correct that this isn't just for KIbana-specific deprecations?

Copy link
Contributor Author

@cjcenizal cjcenizal Nov 9, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

@kobelb kobelb Nov 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@cjcenizal cjcenizal Nov 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@kobelb kobelb Nov 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. I agree that it helps with the Kibana-specific deprecations.


**What can users do to address the change manually?**

<!-- If applicable, describe the manual migration steps and/or link to available docs. -->
Expand Down