Hello,
We are trying to create a set of charms that work on both centos and ubuntu, but are unable to upload the charm to the charm store with centos and ubuntu specified in the metadata.yaml. Would it be possible to enable the charmstore to accept multi-series uploads?
Thanks!
Lol @jamesbeedy
I think I have participated in a 5-6 different threads on this topic =D
I agree on the feature request totally!
This is definitely a situation where I can see both sides. My understanding is that this restriction is considered a feature, not a bug.
Supporting series from multiple operating systems presents a lot of charm complexity. Working with different platforms can be a subtle source of bugs. So the current behaviour is seen as a safety feature.
That said, my view is that we should allow charm authors to write the charms that suit their situation. Writing a single cross-platform charm might be simpler overall, because there is only a single code base to maintain.
I think this argument would make more sense if the charm store would consistently not accept metadata.yaml containing multiple series of Ubuntu. But it does.
It’s mixing centos with Ubuntu that is prohibited.
What is the safety added from prohibit series = [ bionic, centos7] vs allowing [ xenial, bionic ] ?
I can’t see any obvious gain here…
I found this issue from 2016, I still find myself circling these wagons quite often. Is there something specific blocking us from allowing charms to support centos and ubuntu?
Yes, I’m also hit by this from more than one angle.
Also, I think this causes a split in the general juju project itself really.
Consider a team working on a software-stack, lets say BOOBAR. Running and maintaining BOOBAR is complex and juju is selected as the prefered tool to operate BOOBAR. BOOBAR contains perhaps many charms.
Another team wishes to build on BOOBAR charms, but has another system FOOBIN which is primarily running centos.
The team running FOOBIN would at this point not be able to leverage on the knowledge, encapsulated in the BOOBAR charms, provided by the BOOBAR team.
These two teams, both loving juju, would effectively not be able to work together easily to create the logics and code to run BOOBAR and FOOBIN (without introducing complex code patterns outside of juju itself). This creates a divided juju community in two camps: “the centos-camp” and the “ubuntu-camp” which is not growing juju at all.
In the promotional video for juju, its stated that juju should help the creators of these complex systems to build on each others work. I like that statement. However, it didn’t say that “… as long as you run ubuntu”.
I’d like to see that juju by itself would have primitives to manage multiple OS:es consistently. Perhaps by introducing another parameter in the metadata.yaml “os-family:” which would be the higher level division were a blocker would be introduced in charmstore. That would allow series to be mixed like:
os-family: linux
series: [ centos8, bioinc ]
So, a charm would be allowed to be made for linux (any series) while not be allowed for “windows” which would be less of a problem.