DAOS-14514 pmdk: update to version 2.0.1

[grom72]

Upgrade to version 2.0.1.
This version decreases stack usage but does not enable NDCTL.
NDCTL will be enabled with version 2.1.x
Obsolete libraries lbpmemblk and libpmemlog have been removed.

[brianjmurrell]

Do we want this built with or without ndctl at this point in time? Currently it's still being built without:

+ make -j72 EXTRA_CFLAGS=-Wno-error NORPATH=1 BUILD_EXAMPLES=n BUILD_BENCHMARKS=n NDCTL_ENABLE=n

If you want to change this default behaviour you need to change

pmdk/pmdk.spec

Line 27 in 40f6fc0

%bcond_without ndctl

to

 %bcond_with ndctl

That option would then match what the comment above it says.

If you do not want to build with ndctl by default (i.e. the status quo), you can leave the above line as is, but please update the comment to reflect that the default is to build without it. That comment has been wrong ever since the beginning, unfortunately.

Please make sure that NDCTL_ENABLE in

pmdk/debian/rules

Line 8 in 40f6fc0

BUILD_ARGS = prefix=/usr libdir=/usr/lib/$(DEB_HOST_MULTIARCH) sysconfdir=/etc bashcompdir=/usr/share/bash-completion/completions NORPATH=1 NDCTL_ENABLE=n BUILD_EXAMPLES=n BUILD_BENCHMARKS=n

matches the default in daos.spec.

Since you need to push an update anyway, it would be good to update the date/timestamps in the debian/changelog and daos.spec %changelog also.

[brianjmurrell]

Testing on both daos master and release/2.4 are quite the bloodbaths. Surely all of those failures are not unrelated, are they?

PR failing tests release/2.4are a subset of existing failing tests of release/2.4 branch

Just going to -1 until we get to the bottom of that massive amount of failure.

[brianjmurrell]

It would be nice to have a test in daos' ftest subdir that tests and confirms the behaviour that having ndctl enabled provides. This will mitigate any future regressions in regard to this functionality being enabled and working.

That said, we do appear to have test failures in the downstream testing:
master
release/2.4

Do we know that these are unrelated to this update?

[grom72]

It would be nice to have a test in daos' ftest subdir that tests and confirms the behaviour that having ndctl enabled provides. This will mitigate any future regressions in regard to this functionality being enabled and working.

We can add such a test as soon as we enable logging in to the next version of PMDK (2.1.0).
Currently, there is no easy way to check this (at least in the release version).

That said, we do appear to have test failures in the downstream testing: master release/2.4

Do we know that these are unrelated to this update?
Failed tests on the master are related to MDonSSD where PMem (and ndctl) shall not be used at all.

release-2.4 most probably can be ignored as there is no plan to release 2.4.x with NDCTL enabled.

[brianjmurrell]

We can add such a test as soon as we enable logging in to the next version of PMDK (2.1.0). Currently, there is no easy way to check this (at least in the release version).

Can you keep this in mind for a future update of this package?

Failed tests on the master are related to MDonSSD where PMem (and ndctl) shall not be used at all.

Looking at the failure results here it would seem that only a minor number of failures on on SSD and that the lion's share of failures are on the regular Functional Hardware Medium stage. Quite a number of failures there, indeed.

If we look at the master commit that that downstream testing is based on, 91b93c8 and look at it's testing results, there are no hardware testing results due to it being a landing, however if we look at the daily-testing from the same time period (where hardware stages are run) we can see there are quite a bit fewer failures. So we need to understand why there are so many failures in the downstream testing here and if they are known or explainable outside of the changes being made here.

release-2.4 most probably can be ignored as there is no plan to release 2.4.x with NDCTL enabled.

It's not that simple. Any future 2.4.x release will include a PMDK with this PR landed to it. This is why we run downstream testing for all current release branches when we test PRs of dependencies.

Fortunately the failures here are much smaller. Only a single test in fact that just failed on multiple distros.

That only a single test failed on 2.4 is a good sign, but why so many failures on master?

[brianjmurrell]

@jolivier23 You had set this test tag to daosio back in 336f35f. Does it seem reasonable to change that to the more limited pr test set at this point?

Although maybe I am jumping the gun on this one and this is just an interim change to speed up iterating and that will be reverted before the PR is finalized.

Good to at least make a note here to remind myself that this needs investigating if it ends up in the final PR.

[brianjmurrell]

I'm not sure I agree with using this mechanism.

The problem it creates is that if somebody just picks up the SRPM or even just the .spec file for this package and builds it without knowing that our build is using this switch, they get a different result from what we are getting.

Don't get me wrong. I think having switches in the specfile can be useful, but I think we need to always ensure that the result of building without any switches is the result that we want people to get by default. Beyond that, they can use whatever switches they want to intentionally get a different result from our default.

[grom72]

Skipping 2.0.1.
Jumping directly to the new version 2.1.0 with #37