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:
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.