-
Notifications
You must be signed in to change notification settings - Fork 299
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 build.version_qualifier and make security plugin compatible with OpenSearch 1.0.0-rc1 #1179
Add build.version_qualifier and make security plugin compatible with OpenSearch 1.0.0-rc1 #1179
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1179 +/- ##
============================================
+ Coverage 64.57% 64.64% +0.06%
Complexity 3173 3173
============================================
Files 244 244
Lines 17125 17123 -2
Branches 3036 3035 -1
============================================
+ Hits 11059 11069 +10
+ Misses 4522 4509 -13
- Partials 1544 1545 +1
Continue to review full report at Codecov.
|
@@ -45,7 +45,7 @@ jobs: | |||
|
|||
- name: Build OpenSearch | |||
working-directory: ./OpenSearch | |||
run: ./gradlew publishToMavenLocal -Dbuild.snapshot=false | |||
run: ./gradlew publishToMavenLocal -Dbuild.version_qualifier=rc1 -Dbuild.snapshot=false |
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.
What makes this rc1
? The checkout references 1.x
branch that is a moving target.
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, 1.x
is a moving target.
CI checkout 1.x
branch of OpenSearch core, but the version of OpenSearch core is 1.0.0-rc1
for RC, so plugins CI also builds opensearch-1.0.0-rc1
and plugins are required to be built on it. This is an agreement between plugins and OpenSearch core, for example AD and Index Management that have already made the changes.
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.
@cliu123 Please see my comment #1176 (comment) regarding difference between SNAPSHOT
and other tags. Either CI should use https://github.com/opensearch-project/OpenSearch/releases/tag/1.0.0-rc1 or it should use SNAPSHOT
. Mixing both is confusing.
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.
As @dblock mentioned on #1176: "in order for the plugin to start the version of the engine and the plugin will have to match, and the next version is rc1."
I don't really see any potential risks to build OpenSearch with the qualifier rc1
that is consistent with the versions of both OpenSearch core and plugins. It would help to keep consistent across all plugins unless there are risks to do so.
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.
rc1
must correspond to the actual rc1 candidate of OpenSearch, not just to a random/latest commit on the 1.x branch.
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.
@vrozov You're right, what should really happen is that we take an XYZ build of OpenSearch, test it, and label it as rc1
after we're done. However today this is proving itself to be difficult because versions must match across OpenSearch and plugins for everything to start together, including the rc1
qualifier, if any. So it's a chicken and egg problem. I described what we should be doing in opensearch-project/OpenSearch#763, please add your comments.
For this PR I suggest letting it slide to make rc1 because I don't think we can fix 763 in time. But for rc2 or afterwards we should, I'll followup on getting that assigned.
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.
@dblock I don't see a chicken and egg problem here and there was no such problem with the ODFE releases: ES releases first, plugins use released ES artifacts at build, test and runtime. The same process should be followed with Opensearch: rc1
is tagged (best will be to publish artifacts) and plugins should use the tag. Once rc2
is available on Opensearch, plugins should update to that tag. Using latest commit on 1.x
branch, but pretending that it is rc1
makes security plugin build unstable and more importantly testing of security plugin would be done against latest commit, not rc1
, so it can't guarantee that plugin is compatible with the actual rc1
Opensearch.
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 agree.
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.
@MMakaria: this is an ask to effectively change the release train sequence, I had brought it up before
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.
Changing that would make security plugin built on different version/commits of OpenSearch core from other plugins. Let's have a decision before changing this. Whatever the decision is going to be, all plugins will need to take the same action or to stick with building plugins on top of 1.x
branch of OpenSearch core.
…OpenSearch 1.0.0-rc1
af7cefb
to
5041b33
Compare
@@ -45,7 +45,7 @@ jobs: | |||
|
|||
- name: Build OpenSearch | |||
working-directory: ./OpenSearch | |||
run: ./gradlew publishToMavenLocal -Dbuild.snapshot=false | |||
run: ./gradlew publishToMavenLocal -Dbuild.version_qualifier=rc1 -Dbuild.snapshot=false |
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.
rc1
must correspond to the actual rc1 candidate of OpenSearch, not just to a random/latest commit on the 1.x branch.
If OpenSearch was built with -rc1 and this is built with -snapshot I think the plugin will fail to start as the versions must match exactly. See opensearch-project/OpenSearch#763. But it doesn't matter for CI, it can be |
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.
OpenSearch official build is currently building with rc1
, so this needs to be rc1
, or the plugin won't start.
This has been discussed in the comments of the PR.
…OpenSearch 1.0.0-rc1 (opensearch-project#1179)
…OpenSearch 1.0.0-rc1 (opensearch-project#1179)
Signed-off-by: Peter Nied <[email protected]>
opendistro-for-elasticsearch/security pull request intake form
Please provide as much details as possible to get feedback/acceptance on your PR quickly
Category: (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)
Maintenance
Github Issue # or road-map entry, if available:
Description of changes:
Why these changes are required?
OpenSearch release 1.0.0-rc1
What is the old behavior before changes and new behavior after changes? (Please add any example/logs/screen-shot if available)
No changes in behavior
Testing done: (Please provide details of testing done: Unit testing, integration testing and manual testing)
UT
TO-DOs, if any: (Please describe pending items and provide Github issues# for each of them)
Is it backport from main branch? (If yes, please add backport PR # and commits #)
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.