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.
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
Add backward compatibility for elasticsearch<8 #33281
Add backward compatibility for elasticsearch<8 #33281
Changes from 2 commits
db10e2b
38f1d82
e0dcad7
2984194
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
IMO, #33135 should be marked as a breaking change and released with a major bump. This is one argument that we have found, but there could be more such arguments and adding back compat for them will be challenging and will be discovered only when users face issues based on the params they are using.
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.
cc: @Owen-CH-Leung @potiuk @eladkal WDYT?
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 think it indeed HAS potential of breaking things. If we can make it "reasonably compatible" - i.e. fix back-compatibilities that we know and smooth the migration, that would be great, but I would be for marking the next ES release as MAJOR regardless cc: @eladkal
Also there is a little twist to it. Unless I am mistaken, I think elasticsearch handler integration was anyhow broken and not working before :) . So well. it could also be seen as bugfix :P
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 too think we do a major release since the underline dependency had also changed from 7.* to 8.*
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.
Okay. yes +1 to make backward-compatible as much as possible.
I am not aware of how far it was broken. But, we have few tests and users for whom the elasticsearch handler integration was known to be working well. However, only yesterday our tests caught that the PR broke existing working setup :)
Perhaps our QA expert @vatsrahul1001 can provide more confirmation here.
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.
#33135 did not break any airflow code.
We agreed that bumping dependency is not a breaking change and as expected every time you bump x.y.z to x+1.y.z something can be broken for users.
I am not convencied next release should be a major one.
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.
@eladkal , I think if our helm chart can't work with the new Es provider then it should be considered as breaking change.
Also, maybe we should consider bumping to major versions whenever we bump dependencies to major versions?
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.
@eladkal I'm not entirely sure, but the below code was part of airflow's codebase which led to the issue because of upgrade -
airflow/chart/values.yaml
Line 2149 in 01a6c1e
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.
yes, I agree bumping some dependency from x.y.z to x+1.y.z may not need to be a breaking change in general. 👍🏽
However, would like to bring up and discuss the following point.
For this provider, elasticsearch is the main underlying dependency, and we're updating it to the next major version from 7.x to 8.x. It does not affect core Airflow code/functionality, but since providers are versioned and released independently, upgrading to this provider release might affect existing deployments for users.
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.
@ephraimbuddy I didn't see helm tests were broken?
and to my understanding this PR brings back support for elastic search 7 so what is the motivation for the major release? Once this PR is merged the code is backward compatible.
This was discussed and had lazy consequence if I remember correctly. Need to lookup the thread.