Charms for centos - lets begin

[zicklag]

@erik-lonroth

docker will add in a significant overhead to the running device. This will not be good for deployment on small devices where docker might be a no no.

That’s a valid point.

I do think that, if you want to write charms that can run on any distro, you will either have to use containers or something like snaps, flatpaks, etc. . That said, writing charms that run on any distro and having a charming framework that supports any distro are two different things. Maybe you don’t need your charm to run on any distro, but you do need your charming framework to allow you to write a charm for the distro you are interested in.

@erik-lonroth

Also, it will alienate other container architectures such as singularity.

It is very possible that we might extend support to different container engines such as singularity. We could probably even abstract the CLI over the different engines by providing a single way in which to add volumes, environment variables, etc. . If there is a use-case for a different container engine then it would be worth looking into at least.

In fact, if Singularity is lighter-weight than Docker and still supports the Docker image format, then it could be a great option to use with Lucky. I’ll look into it and discuss it with my team.

@erik-lonroth

bash only charms will not be cool. A huge ecosystem of great software will be alienated. I don’t think bash can be default/preferred. It should be supported.

If you don’t mind, I would like to understand a bit more about what would be alienated. What kind of software are you using that would be pushed out?

I come from a background where I’ve written many Docker images and I use bash as the primary method of automation for all of them. My assumption on how charming would be like with Lucky is something like this:

1. I have an application I need to charm, so I write a Docker container for it or I use a container that the vendor has already made.
2. In the charm I add the logic needed to set environment variables, change config files, start/stop the application, etc., all this in response to the Juju hooks and relations I am interested in.

The logic for the charm, I imagine, should be fundamentally simple for most applications. The charm is doing the operations that an operator would otherwise do manually, often with a CLI. My thought is that you would not need Python to accomplish these tasks.

This is just my understanding in the realm of my own experience so I would like to understand more of your use-case.