There are currently 2 major versions included of centos in maas, centos6 and centos7. The minor versions doesn’t show, but supposedly, the latest version is the one supported.
Neither of centos6, nor centos7 have native support for juju (!?). To mitigate that today, we use the ability to upload custom images of centos7 which will override the supported version. This has drawbacks.
- We can’t have more than one single image named “centos7” despite that maas can handle that. So, we need to decide with maas to either divert from the “stock” image in maas (basically rolling our own centos) - or - support deploying with juju. We cant have both.
- If we want to be able to use juju - at all - with maas + centos. We need to modify the image at least to be able to run “python” charms and most notably reactive charms. (This quickly becomes ugly using packer.io for custom image creation.)
The initial thought I have on this, is that the reactive framework of juju really doesn’t stand for itself with juju and any reactive charm. If I decide or need to write a charm for centos, I’m basically left with hooks and bash or a heavily custom centos-image. That’s problematic. For one - it prevents juju from reaching out to anyone having a problem that is not based on Ubuntu. Thats a pitty.
From my limited knowledge of all the interiors of juju, I would suggest that perhaps make the juju machine agent provide all the needed bits-and-pieces to run reactive charms regardless of linux distro - at least be able to stand up “layer-basic” and perhaps write a “layer-yum” that resembles “layer-apt” which would at least be providing the very basics of a reactive framework for yum based distros. Experienced programmers might even think of a generic “layer-package-installer”, but I’m not that person =)
I’ll keep you all posted on the progress and findings.
Below the “images” pane which shows the the two default options for centos in MAAS.