Maintaining centos charms

framework
1

So, we are developing SLURM charms locally to build HPC systems. This field is dominated by rpm distros like centos and runs primarily on bare metal.

We face two large challenges with the juju domain.

  1. MAAS loves Ubuntu, but has poor support for centos although we successfully roll custom centos images. But we run with decreased functionality, for example with storage/partitioning and inability to have more than one centos major version active at any time in MAAS. This makes it hard to upgrade custom images etc. Its not a juju problem, but it spills over to juju… For example, inability to deploy to updated images while keeping an old for rollback purposes.

  2. We need to maintain two separate git code repos for rpm/centos resp. Ubuntu for mostly same functionality which requires double effort maintain and develop the same service - SLURM. It manifests itself for example that the metadata.yaml wont allow series: centos to be mixed with series: bionic. The charmstore wont allow that, git repos need to have separate branches or forks with different content in metadata.yaml and ultimately we end up having to maintain double code for the same service. This is a bad situation for a business primarily using centos/rpm as juju is heavily leaned towards Ubuntu/deb systems and poor on centos.

Although these above are a few issues we have with juju in a centos context , I would be helped with some advice how to keep a single git repo for both centos and Ubuntu to avoid having to duplicate work on our charms and to highligt that juju/maas needs more love on better supporting more than ubuntu distros…

1 Like
2

The new SLURM K8S charms are currently under development and will solve this problem. I’ll touch base here next week when we cut the beta release so you can test them out!

1 Like
3

@hallback might be interested here too.

4

Some of our problems absolutely are related to that we dont know the MAAS system fully. This is our problem, but at times, we would be helped by having access to a knowledge base like a whitepaper or a system architectural blueprint page.

5

@jamesbeedy @rick_h at the moment, I’m faced with a very concrete example.

I have a code-base for a “Active Directory” layer, which purpose is to join a node to an AD-domain using the “realm” command and some configuration rendering. This is straight forward on both ubuntu and centos. The process is identical, and the code could easily live in one repo.

However.

Since charmstore (and charm build?) will not allow metadata.yaml to contain “series: - centos” along with “- bionic”, my code (and subsequent builds and “charm push”) needs to live in separate code repos or branches. This complicate keeping functionality in sync etc.

Now, I must admit - I think this would perhaps be solved by some git magic, or “Makefile” sed/awks ninja, I feel that writing layers/charms that would work transparently on centos/ubuntu/xxxxx would have some kind of mechanism to assist developers to maintain best practice-juju-charms across distros?

To help me out here, how would you go ahead and solve the problem of maintaining charms + code across distros where the content of “metadata.yaml” is the only difference currently - that don’t risk the code logic to diverge due to separate branches/distros?