Open NucciTheBoss opened 1 month ago
I support this, moreso knowing that it's possible that slurmd will get support for jwt in the future.
Though, this also bring an interesting question about having MungeManager
by default, since it could be possible that in the future MungeManager
will be optional. Maybe this is an argument in favour of not having those inside the SlurmManagerBase
class, and be something more like "compose your own class from SlurmManagerClass
, MungeManager
and JwtManager
". 🌮 4️⃣ 🤔
Good idea tbh, although, I think if munge became optional, you and I would need to spend a pulse travelling down to underworld to make sure Satan didn't freeze to death when hell froze over :imp::snowflake::cold_face:
We should add JWT key handling support to
SlurmManagerBase
similar to how we handle munge keys. I went back and forth on this a bit as not all the Slurm daemons support using JWT keys - munge the OG - but I don't think it would hurt us in the long run asslurmctld
,slurmdbd
, andslurmrestd
support using JWT keys.We can enable JWT key support using composition, but without inheriting from the
Service
class:I'm thinking that we add a
jwtctl
tool similarmungectl
, where we can generate, set, and get keys from the command line. That way we directly manage the key in the snap package, and folks can still benefit from the tools that we are creating even if they're not using the charm or snap package.Let me know you thoughts @jedel1043 :eyes: