[RPM M1] Add a new block to call the generation code for RPM #1545
Assignees
Labels
Comments
22 tasks
|
20220204: FPM is having some issues along the way:
Overall, it is a great tool for quick building an RPM without spec file. Still testing. |
peterzhuamazon
changed the title
|
It can finally run now with Test Logs |
1 task
|
PR add rpm block in assemble workflows: #1726 |
1 similar comment
|
PR add rpm block in assemble workflows: #1726 |
1 task
1 task
1 task
|
OSD now support building from opensearch-build for rpm: Logs: |
1 task
1 task
|
New issue 20220407: In 2.0 core branch we have this change from main, and it is not backported to 1.3 branch: In 1.3 branch, due to above change to check In 2.0 because of this change, the above fix in 1.3.x is actually causing 2.0.x to not able to install plugins. Proposed fix: We can then remove the temp fix code in build repo for both 1.3.0 and 2.0.0 to success. Thanks. |
|
@dblock @CEHENKLE @saratvemulapalli Do you have any suggestions for the above issue? |
|
@peterzhuamazon @bbarani I did take a look at the PR. From what I understand, it make the standard path configurable to run multiple OpenSearch instances on the same host. I don't see any harm to have this backported to 1.3 line. As it was called out in the PR, lets make sure this is documented for 1.3 line (more specifically 1.3.2 where this change will be going into). |
|
@bbarani @tianleh @saratvemulapalli
Thanks. |
|
@tianleh @saratvemulapalli @dblock @CEHENKLE @anasalkouz Which option do you suggest to proceed further? |
|
I vote for (3) because there are no hacks. Generally I am against trying to do an RPM release for something that has already shipped (e.g. 1.3.1). We should only be moving forward. |
|
+1 to @dblock. I like 3, as it looks clean. |
dblock
changed the title
dblock
changed the title
Yes it does because it's not the same code. |
Are you suggesting that we have a simultaneous 1.3.1 and 1.3.2 release? I guess I could see that alleviating the need for some different paths like (1) or (2), but I was assuming that was not workable per some earlier comments. I wonder what the use of 1.3.1 would be if 1.3.2 was released simultaneously. It seemed that if we did (3), we would be further punting RPM support to an indeterminate date to the right again. (Not that RPM has any determinate release after being punted from 1.0, 1.1, 1.2, and 1.3 releases - not to mention any release plan per the release notes of 1.3). |
|
I think the question illustrates the kind of confusion we have if we release RPM 1.3.1, 1.3.1 has already been released - https://opensearch.org/docs/latest/version-history/ I don't think we should punt anything, all I am saying is that we should release 1.3.2 TAR and RPM as soon as that's ready. That's the only logical path in my brain, I don't know how to grok "1.3.1 was released March 30th, then 1.3.1 RPM is released April 15th at the same time as taxes were due except when in 2020 there was an extra 15 days grace period" :) |
Oh, I see. I can't use this project until there is real support from RPMs so I didn't even notice the 1.3.1 release.
Yeah, I guess I can't argue with 'as soon as that's ready' except to note that the community desperately needs this feature, it is the largest missing element/feature that never made it over from Elasticsearch, and it is long promised but seems to be continuously deprioritized. As Kyle stated in the forums in November 2021 "RPM and DEB are super vital to serious use for a lot of folks", which I agree completely. |
|
So just to frame the question here. There are three dimensions we can optimize against:
Reading the comments, @dblock it seems like you think the second option (a temp branch) violates number 2 above so much that it outweighs the benefits to 1 and 3. Other voices (mine included) seem to think the second option balances the three concerns the best. Do you have another option that we haven't considered that balances the three concerns better? Or do you still think waiting for 1.3.2 (which optimizes for 2, but is less effective on 1 and 3) is the best option? |
|
(and just a side note: Making 1.3.1 available means making the current version of the 1.x line available in RPM, rather than "re-releasing". Will they always be available on the same day going forward when we release? yes. Should we wait to make that true starting now? I don't think so, but that's how my brain squares that circle, dB). |
|
Just catching up here. Making a 1.3.2 because it has RPM is violation of semver as you're treating it like a feature. If you don't rev the version, then it's not a feature, just like if we added a new build to support RISC-V or something. Patches can only fix bugs - this isn't a bug. |
1 task
|
Hey folks. -- I've slept on it, and we'll make the first RPM 2.0-RC1, and then follow up with a release on 1.3.2. I hate the delay viscerally, but I can't justify the hackery/extra churn on the EE team for the time saved. Thanks. |
Don't worry. No one will be too surprised. |
1 task
Isn't adding RPM in 1.3.1 the same problem as in 1.3.2? So should it be 1.4.0? |
This was referenced Apr 14, 2022
Looks like we finally backported the PR that was the source of contention to 1.3. Does this imply the plan is to release 1.3.1 version rpm along with the 2.0.0 rc1 rpm? |
|
Hi @setiah option 3 is what we are going with: Thanks. |
|
@dblock So, IIRC, the original intention of having the distributions tracked away from numbered versions in the roadmap is that they would not have an effect on the actual logic/features of OpenSearch and could be released out of phase with any particular version. That's fine. No problem with SemVer. Use build metadata that is outside the scope of major.minor.patch. As you're suggesting revving the patch to accommodate this fix doesn't fit the word nor the spirit of SemVer (PATCH version when you make backwards compatible bug fixes ... not this situation at all). Revving the minor doesn't really fit either (MINOR version when you add functionality in a backwards compatible manner ... not really either). I'm suggesting that the project use the build metadata appropriately as per spec. For someone who doesn't care about RPM this version is meaningless. Organizations have policies they have to follow as far as adopting the latest patch, so this is creating waste heat for those users. I'm uncomfortable with the idea of bringing builds back into the numbered versioning scheme yet tracking them in a different place - it's really violating the trust users have in our roadmap and our versioning. All the (rightful) hubbub about RPM being in 1.3.0 roadmap is also meaningless since it was made clear that the distributions shouldn't have been in the numbered version roadmap, and now the project is attaching RPM to a patch version? |
|
Oh, I see. I think 1.3.2 should also get some low hanging CVEs. |
+1, I agree the distribution release process should remain independent of the version release process. This helps with not just the RPM but other distributions such as Windows, Debian as well in future. Else, we could be falling prey to such issues down the line again while releasing other distributions. |
|
@setiah except it's not separate in practice, the rpm process is implemented in a tightly coupled way to the tar release process |
|
Python code can now generate RPMs for both OS and OSD on every version pass 1.3.0. |
|
20220429: Remove PA not properly stopped before install/uninstall |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20220204: We might change to rpmbuild directly without using FPM. See comments.
The text was updated successfully, but these errors were encountered: