I’m trying to create a charm that work for both centos and ubuntu (slurm-node) but when I try to push to charmstore the following bork happens to me:
erik@bionic-dev-1:~/scania-specific$ charm push .
ERROR cannot post archive: unrecognized series “centos” in metadata
erik@bionic-dev-1:~/scania-specific$ vi metadata.yaml
erik@bionic-dev-1:~/scania-specific$ charm build
build: Build dir not specified via command-line or environment; defaulting to /tmp/charm-builds
build: Destination charm directory: /tmp/charm-builds/scania-specific
build: Processing layer: layer:options
build: Processing layer: layer:basic
build: Processing layer: scania-specific (from .)
proof: I: display-name not provided, add for custom naming in the UI
erik@bionic-dev-1:~/scania-specific$ charm push .
ERROR cannot post archive: cannot mix series from centos and ubuntu in single charm
While I can understand the problem of “mixing” series, its not what I would expect to be able to build a charm properly (it deploys and runs just fine) but not being able to push it to charmstore!
The current workaround solution we have is unfortunately to maintain duplicate charms for our centos series. This is not a good situation since we can’t make charms that works across but centos and ubuntu which is a must for us.
We’ve had a policy that in order to encourage charms to be worked on as a group and that there’s enough differences (e.g. install commands are completely different and expected software versions like python versions are different enough) that best practice is to have split charms for different operating systems. Common code can be encapsulated with shared layers between the charms as a way to reduce the maintenance burden. However, you can’t submit charms for both ubuntu/windows or ubuntu/centos or centos/windows.
The charmstore is for shared best practices and while it can work locally we have more strict rules in the charmstore.
That’s the logic of what you’re hitting. We haven’t had many charms in this category and if you’re ok with sharing the repo it’s at I’d be interested in looking at how the differences between OS’s are handled.
I understand the rationale behind that decision of charmstore, which is OK I guess.
The charm I’ve made is really a dirty one. Its a “hooks only” bash version, which basically just install two packages with either yum or apt, depending on series/distro.
The purpose of this charm is to just install some specific packages needed at Scania which doesn’t fit well into the more general SLURM bundle we use. E.g. we don’t want to push these things upstream to OmniVector repos maintained by @jamesbeedy. We try to keep the nasty bits out from that…
However, we end up having to maintain multiple charms even locally where we would like to be able to push it at least to a private namespace…
