My collegue just attempted to push our new null charm and found that he was not allowed to add support for the Centos and Ubuntu series at the same time. That doesn’t make sense to me. While I understand the fact that reactive charms don’t really work on Centos, that is not a limitation for bash charms, and, eventually, it should not be a problem for Lucky charms either. @erik-lonroth has actually published a charm that runs on both with his microsample charm.
I think this restriction should be lifted. Does that make sense to anybody else?
With the Lucky framework, the plan is to do one thing that is specific to the operating system, and that is to install Docker ( or maybe a different container engine ). Aside from that difference, the charm should run the same regardless of the distro because of the containerized application. That difference in how Docker is installed will be handled by the Lucky framework, automatically enforcing the best practice for how to install Docker and removing any platform specific code from the users charm.
Additionally, when it comes to Python support, if and when Lucky gets Python support, it will be designed so that Python is embedded in the Lucky framework itself and will have no dependency on the system Python version.
I think that the bigest reason that we have very few charms that can run on both distros is because there are no tools available for charm developers to write distro agnostic charms. Almost everything out there today is heavily dependent on tools like apt and python that don’t run on both distros, but by building on tools such as Docker or Snap, it should be perfectly possible to write distro agnostic charms with a perfect respect for the best practices.
The ubuntu user. Juju needs its own user which should be a system user rather than posing as a person with a home directory in /home. The ubuntu makes no sense in centos or <distro>.
Charm tools never produce a working charm for centos with ‘charm create -t xxxxxx’, because…
Charm-helpers is broken for everything using anything but ‘apt’ as package manager.
layer-basic is broken for about the same reason. Making anything that uses reactive breaking for anything that is not ‘apt’.
I think that some work is ongoing to try to fix this, but if you build charms today for centos, my strong advice is to stay with bash for now.
I have written another charm for centos which might be an example to look at.
I have written charms that uses patched versions of charm-helpers, layer-basic, layer-options, etc. which are not huge. But those charms are private and until the fixes upstream are in there, I would be hesitant to take that path.
If you desperately want to see an example reactive charm for centos, I have that example here. tiny reactive centos | Juju
As you see in this example charm, part of the problem is that centos7 doesn’t have python3.6+ which seems to be a requirement. So, the workaround is to get juju to modify the os at the cloudinit level - which is a powerful tool, but nasty for deployment of charms.
I do think that a lot of these problems are specific to the reactive framework. Like you said, you can still write bash charms. Lucky charms are similarly freed from those issues by having its own charm template ( lucky charm create ) and not needing Python or apt.
Maybe some of these issues, other than the Python ones, are addressed by the Operator framework, but there isn’t much documentation yet, so I don’t know.
Also, maybe you could package the operator framework with something like PyOxidizer to make it portable regardless of the system Python distribution.
Either way, apparently we have a lack of frameworks that are compatible with multi-distro development, but even if a framework is multi-distro, it would be impossible to push it to the charm store.
I totally resonate with the intent of this, but the user is not proper in this context since ‘ubuntu’ is not really a person.
An audit log would say that “The user ubuntu logged in”. The association with the real user, let’s say erik@external would not be audited.
Further, the home directory /home is problematic since it rules out NFS mounted home-directories with LDAP. In my case, I have to make cloudinit move the ubuntu home directory to /lhome or the NFS would mask the home of ubuntu and prevent any login at all when the NFS service comes online.
Also, the entity ‘ubuntu’ would likely be almost provoking to a centos community =)
Having a system user ‘juju’ with a home directory placed in a /usr/local part of the os would be a way…
