feedback on ldms software collection packaging sought

[baallan]

Hi all,

I've created Software Collection packaging ala redhat for LDMS v4 and things it depends on.

Please review it if you have some time at:
https://github.com/baallan/distribution/tree/master/v43.toss3.opt.stable

Intended benefits of this implementation:

• It allows multiple versions of LDMS v4 (and v3) to be co-installed and run (independently) as system services on the same system image. Non-conflicting configuration of ports, etc is up to the user.
  • This should be a step toward HPs request of incremental migration (not to be confused with the protocol stability requirement, however).
  • This allows performance and other testing of new versions while a production version is undisturbed.
• It eliminates the "relocatability" of LDMS packages and attendant installation madness.
• It is a step in the direction of eliminating the double configure with full arguments, but still some work needed there.
• It provides in a redhat-conventional way the specific python extensions SOS and LDMS need.

Problems of this implementation:

• SLES does not explicitly support the 'software collections' framework for keeping the spec files simple, so we cannot directly apply the spec files on Crays.
• It would be mighty easier for the ovis team and many other packagers if Cray ported the 'software collections' approach to SLES/OpenSUSE and got it included upstream.

@morrone, @bschwal, @jhansonhpe

[morrone]

It is a step in the direction of eliminating the double configure with full arguments, but still some work needed there.

I think that is already, as of 4.3.3, pretty much already no longer necessary. While there is further cleanup we should do, the dist tarball does seem to be in basically functional state. The first run of configure only needs to complete, so that "make dist" can be run. It is only when running configure from the dist tarball that complete arguments are needed. (By the way, someone should upload the dist tarball to github as an attachment to the 4.3.3 release there.)

We just want the dist tarball and spec file. Those are the things that koji needs to make a .src.rpm, and that in turn is what koji uses to build the binary.

Unless there are more details that I am missing, I don't immediately see this being particularly useful for TOSS. If you find it useful for something, and this stuff stays here in a separate repo, then that is fine with me. As long as it doesn't get in the way of the basic tarball+spec file approach, then we won't be impacted.

[baallan]

Redhat seems to be going away in RHEL8 from collections (many on a single host, which is routine for hpc) to streams (exactly 0 or 1 allowed versions of a package per 'host'; presumably they are thinking multiple containers within a host if you want multiple versions of some service).

A problem with packaging SOS for TOSS is that it now depends on python/numpy/cython/pandas and RHEL7 provides (even in collections it seems) no coherent modern version of these. We end up building against anaconda, which is never in the same place across hpc platforms at different institutions and not part of the rpm ecosystem in any case.

[morrone]

I think that using Spack is likely your best choice for installing SOS where it is needed. If you try to go the traditional rpm route, I think you'll probably just wind up having to individually package each missing dependency.

Spack is rapidly becoming the new standard for packaging (above the base system install right now) on HPC systems. It is in heavy use under TOSS 3, and is may very well replace rpm for TCE packaging in TOSS 4.

It looks like there are already spack mainline packages named py-numpy, py-cython, and py-py-pandas, so it might not even be very difficult to get SOS building under spack.

[baallan]

so is spack-built stuff (or tce in general) going to be distributed as part of TOSS4? this would solve a lot of problems for us.

[morrone]

I should think that the TCE stuff is already distributed amongst the trilabs, and I'm not sure why that would stop in the future. So I'm not sure that I understand the question. I'm not sure that anything is official, but spack already has had pretty wide adoption and still expanding rapidly. I think it is a good route to pursue. I at least have no better advice at this point.