[Retrospective] Release version 2.0.0 (RC1)

[peternied]

How to use this issue?
Please add comments to this issue, they can be small or large in scope. Honest feedback is important to improve our processes, suggestions are also welcomed but not required.

What will happen to this issue post release?
There will be a discussion(s) about how the release went and how the next release can be improved. Then this ticket will be updated with the notes of that discussion along side action items.

[peternied]

Security had trouble getting the proper 2.0.0 build for a while, we thought we had done what was needed for the transport client removal, but ended up having to revisit it several times. I'm not sure mechanically what wasn't working (getting the correct build, change propagation delays)

[peternied]

It doesn't look like component issues are being used to track release status, see several issues that do not yet have preparation phases complete (this is a sampling of them)

• Release version 2.0.0 (RC1) OpenSearch#2245
• Release version 2.0.0 (RC1) OpenSearch-Dashboards#1279
• Release version 2.0.0 (RC1) index-management#274

Is there a new process?

[peternied]

Build qualifier switch from 2.0.0-alpha1 -> 2.0.0-rc1 was hard to track

[dblock]

Is there a new process?

No new process, just nobody ran after plugin owners this time around.

[peternied]

The release issue is unreadable with the description being so long and test reports hard to find relevant information to the state of the release.

[bbarani]

How could we have found the issue on the website drop down before day of launch? CC: @CEHENKLE

[peterzhuamazon]

• [Enhancement] Possible gradle plugin to take care of version/qualifier/snapshot #1892
• [Enhancement] Update ci workflow so Dashboards will actually test SNAPSHOT and QUALIFIER OpenSearch-Dashboards#1486
• [Enhancement] Improve tag creation pipeline to skip repositories without write permission for the bot account #1860
• [BUG] New maven sign and upload pipeline fail since 1.3.0 #1893
• [Enhancement] Make input manifest combine version+qualifier like build/bundle manifest or vise versa #1965
• [Build] plugin-helper build script support version qualifier for plugin OpenSearch-Dashboards#1398 (comment)
• [BUG] Min RPM not able to install on AL2 due to arch file name change OpenSearch-Dashboards#1401
• [BUG] Add uninstall for tar integTest between each plugin run #2018
• [Question] Upcoming expiration of our current sub public key (expire on 20220511) #2040
• [BUG] Docker Promotion workflow does not support latest tag even though code is there #2075
• [BUG] Add support for promotion workflow for qualifier and rpm #2076
• [BUG] Core-Plugins installation does not support qualifier fully OpenSearch#3168

[peterzhuamazon]

@anirudha @praveensameneni @bbarani
Let us discuss about managing both OS and OSD plugins within the same repo.

Tagging notificationsDashboards at eb3af31759668a94727950d081e8a3a161f22918 ...
Tagging notifications-core at 482337090e9707e3e00c3538166bc62b45308d28 ...

As we can see OS 2695 use a different commit from notifications than OSD 3015 also in notifications, to build OS and OSD notifications plugins respectively.

This would cause potential discrepancies between OS and OSD build going on.

We need to discuss how to properly manage these plugins and their repos.

Thanks.

[peternied]

Some teams created release tags for rc1, isn't clear what should or should be done as part of post release steps in the component or centralized release issue.

[peterzhuamazon]

Some teams created release tags for rc1, isn't clear what should or should be done as part of post release steps in the component or centralized release issue.

No team is creating tags for rc1, it is already automated from infra side.

• Edit: I just notice security team has a github action to create tags.
  I am not sure why that is the case as the tag is already automated from Infra side.
  Thanks.

[dblock]

Some teams created release tags for rc1, isn't clear what should or should be done as part of post release steps in the component or centralized release issue.

No team is creating tags for rc1, it is already automated from infra side.

• Edit: I just notice security team has a github action to create tags.
  I am not sure why that is the case as the tag is already automated from Infra side.
  Thanks.

Open an issue to delete it.

[kavilla]

It seems like there is expectation for OpenSearch Dashboards (+ plugins) to be prepped and sanity tested complete when OpenSearch (+ plugins) completes. That seems to be broken to me, for minor releases it is achievable, but for major releases it's shouldn't be expected. If any sanity tests found that OpenSearch was invalid then any result during OpenSearch Dashboards should be considered invalid. If we don't, and find out the regression occurs in OpenSearch but then we not spent multiple resources on OpenSearch Dashboards and OpenSearch.

I think for all major releases the RC1 for OpenSearch should be cut and sanity test complete and any regression is fixed prior to the OpenSearch Dashboards beginning it's release cycle (or at least ensure that the release cycle deadlines are not the same). If OpenSearch (+ plugins) needs to check in a bug fix the Friday before release then we should factor that and add buffer time for OpenSearch Dashboards (+ plugins) to react.

[kavilla]

Release notes should not be in the code complete section until after sanity tests are complete. I see multiple repos checking this check box off when anything could happen during sanity testing that requires them to make a change and update their release notes. Release notes can be in draft but I think there should be buffer room to ensure that release notes are the last things that checked off to ensure the accuracy of the notes.

[kavilla]

Build qualifier switch from 2.0.0-alpha1 -> 2.0.0-rc1 was hard to track

I think this was a big miss. I think we prioritized getting an alpha1 build of OpenSearch green which caused a lot of last minute changes to get an rc1 build. OpenSearch plugins needs an rc1 build to switch build no rc1 build existed so then it was a chicken and egg problem which then ended up making the Friday before the week of the initial planned released being the first day an OpenSearch 2.0.0-rc1 build was actually made. Giving initially a few days of sanity tests for OpenSearch and virtually none for OpenSearch Dashboards.

[peternied]

Distribution build breaks were happening constantly, it was hard to know if the build was passing or not. The slack channel #opensearch-distribution-builds seems like it was unmonitored.

[peterzhuamazon]

Close this one and leads to 2.0.0 GA in #2142.