[bug#72766,v2,2/2] gnu: slurm: Enable REST API.

* gnu/packages/parallel.scm (slurm)[inputs]: Add dbus, http-parser, libjwt,
librdkafka, libtaml and (mariadb "dev").
[arguments]: Add --enable-slurmrestd, --with-bpf, --with-http-parser,
--with-rdkafka and --with-yaml to configure flags.

Change-Id: Icddaa8f883754129d975e82fccd732a47a467517
---
 gnu/packages/parallel.scm | 27 +++++++++++++++++++++++----
 1 file changed, 23 insertions(+), 4 deletions(-)

Hello Arun!

Arun Isaac <arunisaac@systemreboot.net> skribis:

> * gnu/packages/parallel.scm (slurm)[inputs]: Add dbus, http-parser, libjwt,
> librdkafka, libtaml and (mariadb "dev").
> [arguments]: Add --enable-slurmrestd, --with-bpf, --with-http-parser,
> --with-rdkafka and --with-yaml to configure flags.
>
> Change-Id: Icddaa8f883754129d975e82fccd732a47a467517

[...]

> +    (inputs (list dbus
> +                  freeipmi
> +                  http-parser
>                    `(,hwloc-2 "lib")
>                    json-c
> +                  libjwt
> +                  librdkafka
> +                  libyaml
>                    linux-pam
> +                  `(,mariadb "dev")

Could you check how this impacts ‘guix size slurm’?

The reason I’m asking is that we at work often end up with slurm in
packs that we carry to supercomputers, so it would be best if it wasn’t
too big:

--8<---------------cut here---------------start------------->8---
$ guix size slurm |tail -1
total: 359.8 MiB
$ guix size slurm mariadb |tail -1
total: 663.4 MiB
--8<---------------cut here---------------end--------------->8---

I wonder if we should have a ‘slurm-minimal’ variant or something?

(That could probably come as a patch after this series.)

Apart from that, both patches look good to me!

Thanks,
Ludo’.

Hi Ludo,

> Could you check how this impacts ‘guix size slurm’?

The size goes up from 141 MiB to 407 MiB.

> The reason I’m asking is that we at work often end up with slurm in
> packs that we carry to supercomputers, so it would be best if it wasn’t
> too big:
>
> --8<---------------cut here---------------start------------->8---
> $ guix size slurm |tail -1
> total: 359.8 MiB
> $ guix size slurm mariadb |tail -1
> total: 663.4 MiB
> --8<---------------cut here---------------end--------------->8---
>
> I wonder if we should have a ‘slurm-minimal’ variant or something?
>
> (That could probably come as a patch after this series.)

Yes, I could add a slurm-minimal. Would you like to have a slurm-minimal
for every version of slurm or just the latest?

Regards,
Arun

Hello!

Arun Isaac <arunisaac@systemreboot.net> skribis:

>> Could you check how this impacts ‘guix size slurm’?
>
> The size goes up from 141 MiB to 407 MiB.

D’oh!

>> I wonder if we should have a ‘slurm-minimal’ variant or something?
>>
>> (That could probably come as a patch after this series.)
>
> Yes, I could add a slurm-minimal. Would you like to have a slurm-minimal
> for every version of slurm or just the latest?

Hmm!  The reason we keep different versions of slurm is because one
always needs a slurm client compatible with the version of slurmd
running on the target cluster.  And so yes, we’d need ‘slurm-minimal’
for each version.

But that doesn’t sound great so I’m not sure.

Another possibility would be to do the opposite: keep ‘slurm’ without
MariaDB & co., and have a ‘slurm-rest’ (?) variant with all the bells
and whistles?

Thanks,
Ludo’.

Hi Ludo,

> Another possibility would be to do the opposite: keep ‘slurm’ without
> MariaDB & co., and have a ‘slurm-rest’ (?) variant with all the bells
> and whistles?

The problem with that approach is that I'm sure there will be more
optional features to add to slurm. Then, we would have a combinatorial
explosion of packages---slurm-rest, slurm-rest+feature1,
slurm-rest+feature2, slurm-feature1+feature2, etc. I am ok with having a
slurm-minimal for all versions. That's the lesser evil.

Regards,
Arun

Hi,

Arun Isaac <arunisaac@systemreboot.net> skribis:

>> Another possibility would be to do the opposite: keep ‘slurm’ without
>> MariaDB & co., and have a ‘slurm-rest’ (?) variant with all the bells
>> and whistles?
>
> The problem with that approach is that I'm sure there will be more
> optional features to add to slurm. Then, we would have a combinatorial
> explosion of packages---slurm-rest, slurm-rest+feature1,
> slurm-rest+feature2, slurm-feature1+feature2, etc.

Not necessarily: that second variant could be maximal, where additional
features would be added.

> I am ok with having a slurm-minimal for all versions. That's the
> lesser evil.

OK.

There might be a third option: moving server-side code to a separate
output.  That way, perhaps client-side code (things like ‘openmpi’)
would not have MariaDB & co. in their closure?

Ludo’.

>> I am ok with having a slurm-minimal for all versions. That's the
>> lesser evil.
>
> OK.

I'll send a v3 patchset with the minimal variants soon..

> There might be a third option: moving server-side code to a separate
> output.  That way, perhaps client-side code (things like ‘openmpi’)
> would not have MariaDB & co. in their closure?

I presume you might need to carry both the server-side and the
client-side code in a guix pack. So, how would this option help?

Morning!

Arun Isaac <arunisaac@systemreboot.net> skribis:

>> There might be a third option: moving server-side code to a separate
>> output.  That way, perhaps client-side code (things like ‘openmpi’)
>> would not have MariaDB & co. in their closure?
>
> I presume you might need to carry both the server-side and the
> client-side code in a guix pack. So, how would this option help?

No, to run code on a supercomputer, you only need MPI and things like
‘salloc’, ‘sbatch’, etc.  There’s definitely no need for ‘slurmd’ or
anything like that in that case because it’s already running on the
machine.

Ludo’.

>> I presume you might need to carry both the server-side and the
>> client-side code in a guix pack. So, how would this option help?
>
> No, to run code on a supercomputer, you only need MPI and things like
> ‘salloc’, ‘sbatch’, etc.  There’s definitely no need for ‘slurmd’ or
> anything like that in that case because it’s already running on the
> machine.

Ah, ok, the server-side is maintained by a different admin team. I was
thinking you were maintaining the server-side as well. That makes sense,
thank you!

In that case, I'll split slurm into two outputs---a server and a
client-side. I'll send a patch in the coming days.