DAOS-18296 common: update PMDK version to 2.1.3 (#17403)

[grom72]

Update and pin PMDK version to 2.1.3.
Point https://github.com/daos-stack/pmdk as the main PMDK reference source.

Requires:

• DAOS-18296 common: update PMDK to version 2.1.3 #17403 as a new PMDK RPMs source

Steps for the author:

• Commit message follows the guidelines.
• Appropriate Features or Test-tag pragmas were used.
• Appropriate Functional Test Stages were run.
• At least two positive code reviews including at least one code owner from each category referenced in the PR.
• Testing is complete. If necessary, forced-landing label added and a reason added in a comment.

After all prior steps are complete:

• Gatekeeper requested (daos-gatekeeper added as a reviewer).

[github-actions]

Ticket title is 'dmg system start causes engines to crash after pool create'
Status is 'Awaiting backport'
Labels: 'scrubbed_2.8'
Job should run at elevated priority (1)
https://daosio.atlassian.net/browse/DAOS-18296

[daosbuild3]

Test stage Test RPMs on EL 8.6 completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-17665/1/execution/node/1225/log

[daosbuild3]

Test stage Functional on EL 8.8 completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos/job/PR-17665/1/display/redirect

[daosbuild3]

Test stage Functional on EL 8.8 completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos/job/PR-17665/1/display/redirect

[grom72]

This is a summary of the validation. It combines several executions because of CI infrastructure failures.
All uses the same commit 44e05c and uses the same binary 2.6.4-19.50.g44e05c28

• Build, Unit tests: daos/job/PR-17665/3
• Functional on EL8.8, Fault injection, Test RPM EL8.6: daos/job/PR-17665/3
• Functional on Leap 15.6: daos/job/PR-17665/4
• Functional Hardware Large: daos/job/PR-17665/5
• Functional Hardware Medium, Functional Hardware Medium Verbs Provider: daos/job/PR-17665/7

Approved to merge

[soumagne]

you should not use =, if for any reason you need a -2 later then you would need another daos package update. I would also do libpmemobj1 >= 2.1.3 don't bother with the -1.suse.lp155

[grom72]

This is the only way to protect 2.6 against an unplanned libpmemobj upgrade.
It is a side effect of switching RPM builds to FPM. We can not verify new dependency package (like libpmeobj) with the 2.6 DAOS version before landing new RPMs to the master. But when they land to the masterthey immediately become available in the artifactory and may impact 2.6 stability. With pin-based approach we can fully control therelease/2.6branch upgrade with a separate PR. I think this is the safer option. It is already implemented on master branch withdaos-spdk` package:

daos/utils/rpms/daos.sh

Line 186 in 7b9f55d

DEPENDS=( "daos = ${VERSION}-${RELEASE}" "daos-spdk = ${daos_spdk_full}" )

This also makes the dependency packages' maintenance and update process more flexible and predictable.
PMDK upgrade to 2.1.3 is a good example.
We need version 2.1.3 for release 2.8, but we also need to predict the impact on DAOS 2.6 and get separate approval. If a package is generally available, we should rely on what the OS vendor delivers (the latest, the best). However, if a package is delivered as part of DAOS, we must be very precise about what we use in validation and what we deliver as complete solution.

[soumagne]

I think that's not the right approach. If for any reason a customer needs an updated package version that includes a patch or anything, then he will be prevented from using the current daos rpm unless an updated daos rpm is also built. We are now imposing additional restrictions on users just because we have a CI issue.
When a 2.8 branch is created, you will then have the exact same issue once you start merging to master and will have to backport to 2.8. What you are saying is true for any package. It does not matter if the package is delivered as part of DAOS or not, this is the exact same reason why linux distributions versions have separate package repositories.
So in my opinion, what it comes down to is this, we need separate artifactory repos for each DAOS branch and more so since once 2.8 is branched, we'll most likely want the fpm changes landing from master to 2.8 to only be reflected once they land.
Now I don't disagree that spdk and libpmem are maybe packages that are really tied to DAOS, but any package is to some extent :) so unless it is a major release change between packages a user should be allowed to install a newer dependency version.

[janekmi]

@soumagne wrote:

If for any reason a customer needs an updated package version that includes a patch or anything, then he will be prevented from using the current daos rpm unless an updated daos rpm is also built.

And this is exactly what we are doing already. We deliver DAOS+dependencies. e.g. You cannot use the latest SPDK and we do anything but pinning to make sure it won't happen e.g. changing the name of the package to have full control over which version the user will use.

We are now imposing additional restrictions on users just because we have a CI issue.

Again, we deliver DAOS+dependencies. The limitation is there already. What pinning does it just prevent the user from making a mistake of using DAOS with any other set of dependencies which is not supported already.

When a 2.8 branch is created, you will then have the exact same issue once you start merging to master and will have to backport to 2.8.

Obviously. And this is a desirable outcome. You have to know exactly when dependencies change. And you want to test these new dependencies in a controlled manner. This is good.

What you are saying is true for any package.

No it is not. It is true only for dependencies we chosen to deliver along with DAOS. DAOS is so fine tuned with particular revisions of these dependencies we decided the user cannot use whatever version comes with their OS distribution.

(...) this is the exact same reason why linux distributions versions have separate package repositories. So in my opinion, what it comes down to is this, we need separate artifactory repos for each DAOS branch and more so since once 2.8 is branched, we'll most likely want the fpm changes landing from master to 2.8 to only be reflected once they land.
Now I don't disagree that spdk and libpmem are maybe packages that are really tied to DAOS, but6 any package is to some extent :) so unless it is a major release change between packages a user should be allowed to install a newer dependency version.

What you propose is something completly new to DAOS.

Till now DAOS was release when it was released. It was DAOS+dependencies we called e.g. DAOS 2.6.4 and it was it.

Whereas with this "OS distribution" model you add a repository e.g. DAOS 2.6 and let's say you install DAOS. Later on you decide you would like to have a newer dependency X so you update just this dependency. Please note our validation does not validate any possible combination of dependencies. There is no "DAOS 2.6.4 + dependency X + 1". And since the dependencies are not pinned all of these combinations will be allowed. Some may say even endorsed. Whereas in fact none of this is supported.

So, the user will end up with a mess.

Am I missing something?

[soumagne]

same comment here

[soumagne]

Still requesting changes because I think we should address the bigger issue related to rpm dependencies and branches (when rpms landing in master are immediately visible to other branches) before we start making that type of change, ie. pinning packages to an exact version.

[daosbuild3]

Test stage NLT on EL 8.8 completed with status UNSTABLE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos//view/change-requests/job/PR-17665/8/testReport/

[daosbuild3]

Test stage Functional Hardware Medium Verbs Provider completed with status UNSTABLE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos//view/change-requests/job/PR-17665/8/testReport/