As we’re working through
charmcraft commands and features, one of the issues we’ve been talking about is what files should
charmcraft build copy into the charm it creates.
One of the things charm developers have told us about the operator framework is that they enjoyed being able to do just
juju deploy . and have everything from their development tree in the charm. This however does come at a cost of complexity on creating and laying out the charm (including needing to get all the runtime dependencies yourself), as well as limitations around what platforms it’s possible to deploy to (namely, only those that exactly match your dev box).
charmcraft is tackling both these via its
build command, but that takes us away from exactly the feature people have told us is nice, to repeat, that the charm deployed is exactly what’s locally.
Now, accomplishing exactly that is easy, we just need to make sure the built charm has everything in it. That’s certainly possible. We can also implement a ‘copy everything that
juju deploy does’, which is not exactly everything but comes close (it skips
However, doing that brings about the risk that we’d be copying secrets into the charm. Keep in mind the charm would then be put in the store, potentially automatically (e.g. by CI), so it could be rather more risky than the development-oriented
juju deploy . command.
On the other hand, not including everything means there will be a situation where the charm does not work and the developer needs to iterate the charm to include things that it didn’t.
So both alternatives are surprising, in different ways. Currently we’re leaning towards copying a limited set of things, with support for specifying more (via a
MANIFEST.in like any python project), because we feel that the surprise of copying secrets is a lot worse than the surprise of missing something.
Does that sound about right? Are there patterns you all are using that would like to be supported ‘by default’? Are we giving the secrets argument too much weight?
Please speak up.