bbarani
commented
1 year ago Bug fixes targeted for 2.11.1 release:
OpenSearch:
Closed github-actions[bot] closed 10 months ago
bbarani
commented
1 year ago OpenSearch:
peternied
commented
1 year ago For reference the fix for that issue was made inside the security plugin, it is in the 2.11 branch:
Having the ref for the security plugin point to 27dee2 to be sure the fix is included in this patch release.
Thank you @Divyaasm
bbarani
commented
1 year ago List of repos that have changes merged in to 2.11 branch post 2.11 release.
CEHENKLE
commented
12 months ago So we need to make a decision about 2.11.1.
A little background first:
1/ We need this release because of a critical breaking bug in the security plug-in. This bug impacts everyone using logstash and the only work around is to turn off compression (which is expensive)
2/ As a refresher, our normal process is to commit changes to main, then backport to 2.x.. Since the 1.0 release, we only backport bug fixes and security changes to the current 2.x branch (in this case 2.11) so that if we need to we can quickly do a patch release we can.
3/ There are two reason we don’t back port features to the current release branch (right now 2.11): a) Because we want patch release to be as thin as possible, and the more changes you make, the more verification we need to do b) Adding features in a patch breaks semver.
However, looking at the list of changes for 2.11, we currently have a mix of features that have been merged in.
Here are the ways forward that we’ve thought of (feel free to suggest another way):
Pros: -- Least disruptive -- Follows SemVer
Cons: -- We are broken with logstash, and the only work around in place is not scalable (turn compression off) and costs more money -- The high severity fixes will not be released quickly
Ship 2.11.1 as-is with features using 2.11 branch
Create 2.11.1 branch and use commits from 2.11 release ( and cherry pick only necessary bug fixes in to 2.11.1 branch)
Release 2.12 version instead of 2.11.1 version to accommodate new features
Revert all feature related changes from 2.11 branch
As you can see, there’s no solution without cons, but given all the trade-offs, I’m leaning towards 1. WDYT?
Thanks,
PS, because this is impacting people today, I’d like to get this release out ASAP. So please put your comments up in the next 48 hours so we can prep a release for early next week (if that's what we're going to do). I also want to better understand why features were backported to the release branch, and what we should do about this in the future, but I’d like to tackle that after 2.11.1 is out.
reta
commented
12 months ago Thanks @CEHENKLE
- Ship 2.11.1 as-is with features using 2.11 branch
+1 to this option, for OpenSearch core at least, out of 3 merged pull requests, 2 are non-functional changes and 1 is a bugfix (with accordance to semver and signed off by the team before the merge). For a plugins though (except security one) would be good to hear maintainers.
smortex
commented
12 months ago However, looking at the list of changes for 2.11, we currently have a mix of features that have been merged in.
:no_mouth: That's unexpected. It feels like a lot of these backports PR where opened with some automation due to improper labels being put on the initial PR (i.e. a feature should only have been labeled backport-2.x and a bugfix should have been labeled backport-2.x and backport-2.10). Maybe ensuring each PR is labelled as a backwards-incompatible, enhancement or bugfix can be used with this automation to detect inconsistencies and avoid this situation in the future? Is there a PR to discuss this?
| # | Scenario | My feeling |
|---|---|---|
| 0 | Ship nothing, wait until Jan 2.12 | LGTM but does not looks acceptable for some users :upside_down_face: |
| 1 | Ship 2.11.1 as-is with features using 2.11 branch | Strong no go: if we do this on purpose we should really stop pretending we are doing something that connects even marginally with SemVer. When this happen by accident, SemVer has a FAQ entry to describe how it should be handled (basically scenario 5) |
| 2 | Create 2.11.1 branch and use commits from 2.11 release ( and cherry pick only necessary bug fixes in to 2.11.1 branch) | That is basically having a 2.11.1 branch that contains what 2.11 was supposed to have. I wonder if keeping the 2.11 branch at it is makes sense in this case, because a 2.11.2 version would be branched out of the 2.11.1 branch is another patch release is to be issued |
| 3 | Release 2.12 version instead of 2.11.1 version to accommodate new features | LGTM |
| 4 | Revert all feature related changes from 2.11 branch | LGTM |
Given the situation, 0 & 3 seems the most practical (bump minor version and release), 4 is probably the cleanest thing we can do but require more efforts (allows us to bump the patch version and release).
Branching 2.12 from 2.11 instead of 2.x and releasing the 2.12.0 version from there seems to require the minimum efforts and would have my preference because it looks to require reasonable effort (scenario 3).
If the cost regarding community trust of releasing 2.12 earlier than announced and without the announced features of 2.12 seems problematic, scenario 4 is probably what must be done IMHO.
If both are too much pain, as a last resort scenario 0 is acceptable.
peternied
commented
12 months ago Chiming in for Security, I would advocate for option 1, as its the smallest deviation from our existing process and I trust that maintainers are making the right choices.
For me the most important trait of following Semver is signaling breaking changes on major version changes, secondarily is signaling potential risk between minor/patch versions. The sematic argument of 'is it a feature or a bug' is hard to judge on a product of this scale.
Changing the process mid-flight is risky - I'd advocate for doing a retro afterwards to drill into misaligned expectations around branches / release.
macohen
commented
12 months ago I think that this should be the 2.12 release. We know there are features and bugs in this release. We need to be careful with testing and make sure we're confident in the release. It's a slippery slope to make exceptions on semver, but continue to say that we follow it. We should also have a retro meeting after the fact that involves representatives from interested parties who take these releases into their products/services.
joshuarrrr
commented
12 months ago In terms of level of effort, options 2 and 4 seem comparable/equivalent, but 4 gets us to a proper/desired state where we'd prefer to be, whereas option 2 deviates our process quite a bit.
I trust that maintainers are making the right choices.
But we have evidence that's not the case - maintainers are responsible for adding the labels which triggers the backport automation and have (intentionally or not) violated semver by improperly backporting features to the 2.11 branch.
dblock
commented
12 months ago I recommend rewinding all 2.11 to the 2.11 release, then applying only security fixes on top, aka reverting anything that's not a security fix from 2.11. If there were a critical security vulnerability right now we would have to do that. If we ship 2.11.1 with the additional commits we won't be able to do a 2.11.2 just with security fixes, forcing these features onto users who have standard practices around semver.
At the same time, we can ship 2.12 with these features as always.
reta
commented
12 months ago I recommend rewinding all 2.11 to the 2.11 release, then applying only security fixes on top, aka reverting anything that's not a security fix from 2.11.
.. and bugfixes (this fits semver), for OpenSearch core there was deliberate decision to bring the bugfix to 2.11.1 (see please Slack discussion in #release channel).
austintlee
commented
12 months ago @dblock you're endorsing option 4, correct?
That is the best option in my opinion. If we ever have to do a 2.11.2, you would want 2.11.1 to be in the state that db is describing.
krisfreedain
commented
12 months ago I would agree - if we do a 2.11.1, it should follow Semver and only be bug fixes. Vote for option 4 - then we can move any feature-related work to 2.12
stephen-crawford
commented
12 months ago I also vote for option #4. I don't think that tossing semver is a good call and some of the changes seem pretty substantial. For example:
https://github.com/opensearch-project/sql/commit/6e17ae6f9d8deceb89616c3bde1915167d25c7a2
None of these seem like bug fixes to me and we should not say we are semver if we are not.
That leaves releasing 2.12 now or reverting changes.
I don't think we should release now, since I doubt that will be easier than reverting and don't love having such a thin/rushed version.
That leaves reverting as the best choice in my opinion.
CEHENKLE
commented
12 months ago Okay, seems like we're coalescing around number 4 (Revert all feature related changes from 2.11 branch, release 2.11.1 from there). We'll put a meta issue up (linked here) with sub issues for each feature added, and track the removal here. When they're all closed, we'll cut the release.
In the spirit of many eyes make shallow bugs, everyone feel free to cross check the issues ID'd in the meta issue once it's up to make sure we didn't miss anything.
Thanks,
gaiksaya
commented
12 months ago The META issue is up with all child issues linked to it: https://github.com/opensearch-project/opensearch-build/issues/4199 Thanks!
Divyaasm
commented
11 months ago One more change that's targeted for the 2.11.1 release
OpenSearch:
bbarani
commented
11 months ago The below issues needs to be resolved to unblock the 2.11.1 release.
bbarani
commented
11 months ago Pending Security PR:
davidlago
commented
11 months ago @bbarani @CEHENKLE there is a SAML regression discovered last minute that we'll need to get into 2.11.1. A PR to fix it is already out, needs some reviews and hopefully can be merged/backported to 2.11 in the next few hours:
Divyaasm
commented
11 months ago Build failing for performance-analyzer - Build 8841 Related logs
davidlago
commented
11 months ago @bbarani security bugfix merged, once this backport merges we should be good to go on that end:
Divyaasm
commented
11 months ago OpenSearch DashBoards critical CVE fix:
Divyaasm
commented
11 months ago OpenSearch - Build 8873 OpenSearch Dashboards - Build 6816
Use the following Docker-Compose to setup a cluster
version: '3'
services:
opensearch-node1:
image: opensearchstaging/opensearch:2.11.1.8873
container_name: opensearch-node1
environment:
- cluster.name=opensearch-cluster
- node.name=opensearch-node1
- discovery.seed_hosts=opensearch-node1,opensearch-node2
- cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
- bootstrap.memory_lock=true # along with the memlock settings below, disables swapping
- "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # minimum and maximum Java heap size, recommend setting both to 50% of system RAM
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536 # maximum number of open files for the OpenSearch user, set to at least 65536 on modern systems
hard: 65536
volumes:
- opensearch-data1:/usr/share/opensearch/data
ports:
- 9200:9200
- 9600:9600 # required for Performance Analyzer
networks:
- opensearch-net
opensearch-node2:
image: opensearchstaging/opensearch:2.11.1.8873
container_name: opensearch-node2
environment:
- cluster.name=opensearch-cluster
- node.name=opensearch-node2
- discovery.seed_hosts=opensearch-node1,opensearch-node2
- cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
- bootstrap.memory_lock=true
- "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536
hard: 65536
volumes:
- opensearch-data2:/usr/share/opensearch/data
networks:
- opensearch-net
opensearch-dashboards:
image: opensearchstaging/opensearch-dashboards:2.11.1.6816
container_name: opensearch-dashboards
ports:
- 5601:5601
expose:
- "5601"
environment:
OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]'
networks:
- opensearch-net
volumes:
opensearch-data1:
opensearch-data2:
networks:
opensearch-net:
docker-compose pull.docker-compose up.docker pull opensearchstaging/opensearch:2.11.1.8873 && docker run -it -p 9200:9200 -e "discovery.type=single-node" -e "DISABLE_SECURITY_PLUGIN=true" opensearchstaging/opensearch:2.11.1.8873curl https://localhost:9200/docker pull opensearchstaging/opensearch:2.11.1.8873 && docker run -it -p 9200:9200 -e "discovery.type=single-node" opensearchstaging/opensearch:2.11.1.8873curl --insecure https://admin:admin@localhost:9200/OpenSearch-Dashboards docker 2.11.1.6816
docker pull opensearchstaging/opensearch-dashboards:2.11.1.6816 && docker run -it --network="host" -e "DISABLE_SECURITY_DASHBOARDS_PLUGIN=true" opensearchstaging/opensearch-dashboards:2.11.1.6816https://localhost:5601/docker pull opensearchstaging/opensearch-dashboards:2.11.1.6816 && docker run -it --network="host" opensearchstaging/opensearch-dashboards:2.11.1.6816https://localhost:5601/Use TARs to deploy OpenSearch Manually
Check how to install opensearch and dashboards on different platforms
Divyaasm
commented
11 months ago OpenSearch - Build 8875 OpenSearch Dashboards - Build 6816
Use the following Docker-Compose to setup a cluster
version: '3'
services:
opensearch-node1:
image: opensearchstaging/opensearch:2.11.1.8875
container_name: opensearch-node1
environment:
- cluster.name=opensearch-cluster
- node.name=opensearch-node1
- discovery.seed_hosts=opensearch-node1,opensearch-node2
- cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
- bootstrap.memory_lock=true # along with the memlock settings below, disables swapping
- "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # minimum and maximum Java heap size, recommend setting both to 50% of system RAM
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536 # maximum number of open files for the OpenSearch user, set to at least 65536 on modern systems
hard: 65536
volumes:
- opensearch-data1:/usr/share/opensearch/data
ports:
- 9200:9200
- 9600:9600 # required for Performance Analyzer
networks:
- opensearch-net
opensearch-node2:
image: opensearchstaging/opensearch:2.11.1.8875
container_name: opensearch-node2
environment:
- cluster.name=opensearch-cluster
- node.name=opensearch-node2
- discovery.seed_hosts=opensearch-node1,opensearch-node2
- cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
- bootstrap.memory_lock=true
- "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536
hard: 65536
volumes:
- opensearch-data2:/usr/share/opensearch/data
networks:
- opensearch-net
opensearch-dashboards:
image: opensearchstaging/opensearch-dashboards:2.11.1.6816
container_name: opensearch-dashboards
ports:
- 5601:5601
expose:
- "5601"
environment:
OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]'
networks:
- opensearch-net
volumes:
opensearch-data1:
opensearch-data2:
networks:
opensearch-net:
docker-compose pull.docker-compose up.docker pull opensearchstaging/opensearch:2.11.1.8875 && docker run -it -p 9200:9200 -e "discovery.type=single-node" -e "DISABLE_SECURITY_PLUGIN=true" opensearchstaging/opensearch:2.11.1.8875curl https://localhost:9200/docker pull opensearchstaging/opensearch:2.11.1.8875 && docker run -it -p 9200:9200 -e "discovery.type=single-node" opensearchstaging/opensearch:2.11.1.8875curl --insecure https://admin:admin@localhost:9200/OpenSearch-Dashboards docker 2.11.1.6816
docker pull opensearchstaging/opensearch-dashboards:2.11.1.6816 && docker run -it --network="host" -e "DISABLE_SECURITY_DASHBOARDS_PLUGIN=true" opensearchstaging/opensearch-dashboards:2.11.1.6816https://localhost:5601/docker pull opensearchstaging/opensearch-dashboards:2.11.1.6816 && docker run -it --network="host" opensearchstaging/opensearch-dashboards:2.11.1.6816https://localhost:5601/Use TARs to deploy OpenSearch Manually
Check how to install opensearch and dashboards on different platforms
Divyaasm
commented
11 months ago x64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6514/pipeline
Failed plugins:
| alerting | with-security | FAIL |
| security-analytics | with-security | FAIL |
arm64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6513/pipeline
Failed plugins:
| alerting | with-security | FAIL |
Failed plugins:
| OpenSearch-Dashboards | with-security | FAIL |
| OpenSearch-Dashboards | without-security | FAIL || alertingDashboards | with-security | FAIL |
| alertingDashboards | without-security | FAIL || observabilityDashboards | with-security | FAIL |
Failed plugins:
| OpenSearch-Dashboards | with-security | FAIL |
| OpenSearch-Dashboards | without-security | FAIL || alertingDashboards | with-security | FAIL |
| alertingDashboards | without-security | FAIL |We couldn't finalize a release candidate build for 2.11.1 release due to last minute issues in OSD along with missing release notes in multiple repositories. We have moved the release date for 2.11.1 to Nov 27 2023 to accommodate the fixes. Please let us know if you have any questions.
pjfitzgibbons
commented
11 months ago I signoff dashboardsObservability plugin "with security" integ test - we have test manually with success.
kavilla
commented
11 months ago I signoff OpenSearch Dashboards integ tests - we have tested those manually and so success. We will do a quick follow to ensure test success on the official job.
cc: @manasvinibs
Divyaasm
commented
11 months ago [x] Promote Repos.
[x] Promote Artifacts.
[x] Consolidated Release Notes. https://github.com/opensearch-project/opensearch-build/pull/4237
Completed validation for <> in the logs)
https://build.ci.opensearch.org/blue/organizations/jenkins/distribution-validation/detail/distribution-validation/20/pipeline
https://build.ci.opensearch.org/blue/organizations/jenkins/distribution-validation/detail/distribution-validation/22/pipeline
https://build.ci.opensearch.org/blue/organizations/jenkins/distribution-validation/detail/distribution-validation/23/pipelinebbarani
commented
11 months ago All, Maven publishing part is delayed due to this issue. We will publish it to Maven as soon as the issue is fixed
bbarani
commented
11 months ago Hello all, we discovered that few enhancements were merged in to the final release candidate of 2.11.1 version deviating from SemVar guidelines. We have requested the maintainers of the repo to revert the changes. We have moved the 2.11.1 release to Nov 30 2023 to accommodate the changes.
Divyaasm
commented
11 months ago Awaiting for the merge of the revert PR's with features and enhancements before moving forward with the 2.11.1 release
Divyaasm
commented
11 months ago OpenSearch - Build 8933 OpenSearch Dashboards - Build 6867
Use the following Docker-Compose to setup a cluster
version: '3'
services:
opensearch-node1:
image: opensearchstaging/opensearch:2.11.1.8933
container_name: opensearch-node1
environment:
- cluster.name=opensearch-cluster
- node.name=opensearch-node1
- discovery.seed_hosts=opensearch-node1,opensearch-node2
- cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
- bootstrap.memory_lock=true # along with the memlock settings below, disables swapping
- "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # minimum and maximum Java heap size, recommend setting both to 50% of system RAM
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536 # maximum number of open files for the OpenSearch user, set to at least 65536 on modern systems
hard: 65536
volumes:
- opensearch-data1:/usr/share/opensearch/data
ports:
- 9200:9200
- 9600:9600 # required for Performance Analyzer
networks:
- opensearch-net
opensearch-node2:
image: opensearchstaging/opensearch:2.11.1.8933
container_name: opensearch-node2
environment:
- cluster.name=opensearch-cluster
- node.name=opensearch-node2
- discovery.seed_hosts=opensearch-node1,opensearch-node2
- cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
- bootstrap.memory_lock=true
- "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536
hard: 65536
volumes:
- opensearch-data2:/usr/share/opensearch/data
networks:
- opensearch-net
opensearch-dashboards:
image: opensearchstaging/opensearch-dashboards:2.11.1.6867
container_name: opensearch-dashboards
ports:
- 5601:5601
expose:
- "5601"
environment:
OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]'
networks:
- opensearch-net
volumes:
opensearch-data1:
opensearch-data2:
networks:
opensearch-net:
docker-compose pull.docker-compose up.docker pull opensearchstaging/opensearch:2.11.1.8933 && docker run -it -p 9200:9200 -e "discovery.type=single-node" -e "DISABLE_SECURITY_PLUGIN=true" opensearchstaging/opensearch:2.11.1.8933curl http://localhost:9200/docker pull opensearchstaging/opensearch:2.11.1.8933 && docker run -it -p 9200:9200 -e "discovery.type=single-node" opensearchstaging/opensearch:2.11.1.8933curl --insecure https://admin:admin@localhost:9200/OpenSearch-Dashboards docker 2.11.1.6867
docker pull opensearchstaging/opensearch-dashboards:2.11.1.6867 && docker run -it --network="host" -e "DISABLE_SECURITY_DASHBOARDS_PLUGIN=true" opensearchstaging/opensearch-dashboards:2.11.1.6867http://localhost:5601/docker pull opensearchstaging/opensearch-dashboards:2.11.1.6867 && docker run -it --network="host" opensearchstaging/opensearch-dashboards:2.11.1.6867https://localhost:5601/Use TARs to deploy OpenSearch Manually
Check how to install opensearch and dashboards on different platforms
Divyaasm
commented
11 months ago x64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6515/pipeline
arm64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6516/pipeline
All components integration tests are passing for OpenSearch
Failed plugins:
| OpenSearch-Dashboards | with-security | FAIL |
| OpenSearch-Dashboards | without-security | FAIL |Check the test-report manifest in the issue for logs related to OSD integ-test failure
Failed plugins:
| OpenSearch-Dashboards | with-security | FAIL |
| OpenSearch-Dashboards | without-security | FAIL |Check the test-report manifest in the issue for logs related to OSD integ-test failure
kavilla
commented
11 months ago Manual sign off on those tests. Currently working on it: https://github.com/opensearch-project/OpenSearch-Dashboards/issues/5506
Divyaasm
commented
11 months ago OpenSearch - Build 8942 OpenSearch Dashboards - Build 6867
Use the following Docker-Compose to setup a cluster
version: '3'
services:
opensearch-node1:
image: opensearchstaging/opensearch:2.11.1.8942
container_name: opensearch-node1
environment:
- cluster.name=opensearch-cluster
- node.name=opensearch-node1
- discovery.seed_hosts=opensearch-node1,opensearch-node2
- cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
- bootstrap.memory_lock=true # along with the memlock settings below, disables swapping
- "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # minimum and maximum Java heap size, recommend setting both to 50% of system RAM
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536 # maximum number of open files for the OpenSearch user, set to at least 65536 on modern systems
hard: 65536
volumes:
- opensearch-data1:/usr/share/opensearch/data
ports:
- 9200:9200
- 9600:9600 # required for Performance Analyzer
networks:
- opensearch-net
opensearch-node2:
image: opensearchstaging/opensearch:2.11.1.8942
container_name: opensearch-node2
environment:
- cluster.name=opensearch-cluster
- node.name=opensearch-node2
- discovery.seed_hosts=opensearch-node1,opensearch-node2
- cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
- bootstrap.memory_lock=true
- "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536
hard: 65536
volumes:
- opensearch-data2:/usr/share/opensearch/data
networks:
- opensearch-net
opensearch-dashboards:
image: opensearchstaging/opensearch-dashboards:2.11.1.6867
container_name: opensearch-dashboards
ports:
- 5601:5601
expose:
- "5601"
environment:
OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]'
networks:
- opensearch-net
volumes:
opensearch-data1:
opensearch-data2:
networks:
opensearch-net:
docker-compose pull.docker-compose up.docker pull opensearchstaging/opensearch:2.11.1.8942 && docker run -it -p 9200:9200 -e "discovery.type=single-node" -e "DISABLE_SECURITY_PLUGIN=true" opensearchstaging/opensearch:2.11.1.8942curl http://localhost:9200/docker pull opensearchstaging/opensearch:2.11.1.8942 && docker run -it -p 9200:9200 -e "discovery.type=single-node" opensearchstaging/opensearch:2.11.1.8942curl --insecure https://admin:admin@localhost:9200/OpenSearch-Dashboards docker 2.11.1.6867
docker pull opensearchstaging/opensearch-dashboards:2.11.1.6867 && docker run -it --network="host" -e "DISABLE_SECURITY_DASHBOARDS_PLUGIN=true" opensearchstaging/opensearch-dashboards:2.11.1.6867http://localhost:5601/docker pull opensearchstaging/opensearch-dashboards:2.11.1.6867 && docker run -it --network="host" opensearchstaging/opensearch-dashboards:2.11.1.6867https://localhost:5601/Use TARs to deploy OpenSearch Manually
Check how to install opensearch and dashboards on different platforms
Divyaasm
commented
11 months ago x64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6524/pipeline arm64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6526/pipeline
All components integration tests are passing for OpenSearch
Failed plugins:
| OpenSearch-Dashboards | with-security | FAIL |
| OpenSearch-Dashboards | without-security | FAIL |Check the test-report manifest in the issue for logs related to OSD integ-test failure
Failed plugins:
| OpenSearch-Dashboards | with-security | FAIL |
| OpenSearch-Dashboards | without-security | FAIL |Check the test-report manifest in the issue for logs related to OSD integ-test failure
bbarani
commented
11 months ago Validated signatures:
gpg --verify opensearch-2.11.1-linux-x64.tar.gz.sig opensearch-2.11.1-linux-x64.tar.gz
gpg: Signature made Thu Nov 30 11:34:31 2023 PST
gpg: using RSA key C2EE2AF6542C03B4
gpg: Good signature from "OpenSearch project <opensearch@amazon.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: C5B7 4989 65EF D1C2 924B A9D5 39D3 1987 9310 D3FC
Subkey fingerprint: 2187 3199 B103 0FCD 49DA 83F8 C2EE 2AF6 542C 03B4Native Plugin Installation:
./opensearch-plugin install repository-s3
-> Installing repository-s3
-> Downloading repository-s3 from opensearch
[=================================================] 100%
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: plugin requires additional permissions @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
* java.io.FilePermission config#plus read
* java.lang.RuntimePermission accessDeclaredMembers
* java.lang.RuntimePermission getClassLoader
* java.lang.RuntimePermission setContextClassLoader
* java.lang.reflect.ReflectPermission suppressAccessChecks
* java.net.NetPermission setDefaultAuthenticator
* java.net.SocketPermission * connect,resolve
* java.util.PropertyPermission aws.configFile read,write
* java.util.PropertyPermission aws.sharedCredentialsFile read,write
* java.util.PropertyPermission opensearch.allow_insecure_settings read,write
* java.util.PropertyPermission opensearch.path.conf read,write
See http://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html
for descriptions of what these permissions allow and the associated risks.
Continue with installation? [y/N]y
-> Installed repository-s3 with folder name repository-s3
Release OpenSearch and OpenSearch Dashboards 2.11.1
I noticed that a manifest was automatically created in manifests/2.11.1. Please follow the following checklist to make a release.
How to use this issue
## This Release Issue This issue captures the state of the OpenSearch release, its assignee (Release Manager) is responsible for driving the release. Please contact them or @mention them on this issue for help. There are linked issues on components of the release where individual components can be tracked. For more information check the the [Release Process OpenSearch Guide](https://github.com/opensearch-project/opensearch-build/blob/main/RELEASE_PROCESS_OPENSEARCH.md).
Please refer to the following link for the release version dates: Release Schedule and Maintenance Policy.
Preparation
Campaigns
Release Branch and Version Increment - Ends Nov 14 2023
Feature Freeze
Code Complete - Ends date
Release Candidate Creation and Testing - Ends Nov 21 2023
Pre Release - Ends Nov 24 2023
Release - Ends Nov 27 2023
Release Checklist.
Release Checklist
### Pre-Release activities - [x] Promote Repos. - - [ ] OS - - [ ] OSD - [ ] Promote Artifacts. - - [ ] Windows - - [ ] Linux Debian - - [ ] Linux RPM - - [ ] Linux TAR - [ ] Consolidated Release Notes. ### Release activities - [ ] Docker Promotion. - [ ] Release Validation part 1. - - [ ] OpenSearch and OpenSearch Dashboard Validation. - - [ ] Validate the native plugin installation. - [ ] Merge consolidated release notes PR. - [ ] Website and Documentation Changes. - - [ ] Merge staging website PR. - - [ ] Promote the website changes to prod. - - [ ] Add website alert. - [ ] Release Validation part 2. - - [ ] Validate the artifact download URL's and signatures. - [ ] Release Validation part 3. - - [ ] Trigger the validation build (Search for `Completed validation for <>` in the logs). - [ ] Maven Promotion. - [ ] Publish blog posts. - [ ] Advertise on Social Media. - [ ] Post on public slack and Github Release issue. ### Post-Release activities - [ ] Release Tags. - [ ] Input Manifest Update. - [ ] Decrease the Build Frequency. - [ ] OpenSearch Build Release notes. - [ ] Retrospective Issue. - [ ] Helm and Ansible Playbook release. - [ ] Upcoming Release Preparation.
Post Release
Components
Replace with links to all component tracking issues.
Legend
| Symbol | Meaning | | -------- | ---------- | | :green_circle: | On track with overall release | | :yellow_circle: | Missed last milestone | | :red_circle: | Missed multiple milestones |