I’ve got some charms now, and wondering if layering is supported only by Operator Framework… or if plain ol’ bash charms somehow can utilize layers? I’m sure I could do some tricks to get something going with shared bash scripts but it feels like not a great way to go about this… and the other next step would be to rewrite things in the python frameworks which has its own difficulties
The Operator Framework, which uses charmcraft, is Python only and doesn’t use layers, instead using standard Python dependency management.
Edit: Disregard this, and see my follow-up reply below.
It sounds like you’re talking about charms using the older charms.reactive and charm snap (for charm build). While it is technically possible to write reactive code in bash, as mentioned in the documentation, I would very strongly recommend against it and instead investing the effort in learning and using the new Operator Framework instead, as it makes charm logic easier to follow and reason about, and has better debugging and testing tools. The maintenance burden for a charm using reactive in general, and especially with bash, is going to quickly surpass the initial investment needed to move to the Operator Framework.
Not as-is. Maybe something akin to layers? I could certainly see a set of bash functions being re-used between charms. It would take some infrastructure to support though. Bash doesn’t have many facilities for keeping things isolated, such as namespacing.
I realized after re-reading the OP that you’re not actually looking to use reactive, just the layer combination aspect. That’s actually a significantly easier prospect since, while charm build assumes you’ll be using reactive, it doesn’t actually require it. You could in fact do this by including a layer.yaml which does not include layer:basic (or layer:caas-base) and it should pretty much just work.
The one caveat that I can think of is that the build process does make a hard assumption (requirement) that you’re using a hooks.template file to simulate a single-entry-point charm. Since this has now been implemented in Juju proper in 2.8, I think it would be worth changing that to not be a hard requirement, or at least to allow for using the dispatch mechanism rather than the hook template system currently built in to charm build.
Another possible approach would be to use git submodules or sub-trees.
I normally use a ./lib/stuff.bash structure to load up library functions for bash but that’s perhaps not what you are looking for?
1 Like
When we started this charming adventure, we thought enabling ‘any language’ would make things easier. Now I feel the opposite, that it’s better to treat charms as ‘proper applications’ and use a language which has good testing mechanisms. This has the extra advantage that it makes sharing code much easier, which is important for relations between charms.
So, as tempting as it is to use bash for a quick charm, I think there are real rewards to using a higher level language. And I would be very grateful for any suggestions folks have as to how we can improve the tutorials, docs, and first-charm experience for the Python operator framework.
1 Like