All Thursdays, starting March 31st 2022, between 16:00 and 17:00 UTC a member of the Charmcraft team will host an open session during which we can talk about using, building and publishing charms. It will be hosted through Google Meet.
It is a hands-on working/troubleshooting session open to all Charmcraft developers, including the wider community. This is a great opportunity for all of us to brainstorm fixes, as well identify and prioritize bugs within the team.
If you’re having trouble building or publishing charms, feel free to join us for an interactive session of debugging. The session will not be recorded and will not be live-streamed. People are also welcome to join and just listen - and learn too (just ensure to mute your microphone when not talking).
If you have specific issues or problems you are facing with your charms, please post a brief description in a post below. These posts will be a good starting point for our sessions.
Not yet. My idea is to start talking about developers issues and inconveniences, so it would be super great if you annotate topics to talk (as answers in this post). The fallback is to present the new stuff in 1.5 and what comes next.
Is there a way to install apt packages (like python-dev) in the charm like the way we install Python packages with the charm-python-packages part? Or the way to do that is through resources (like deb files)? I’m thinking about bundling some packages in the charm for an offline install requirement that we have.
Is it ok to call a Juju hook tool like, for example, juju relation-set, inside the workload that was deployed by the charm (instead of calling it in the charm code)? UPDATE: For this, seems like we can use something like juju-run -u unit JUJU_DISPATCH_PATH=hooks/metrics_endpoint_change {}/dispatch, so it’s solved.
Is it possible to pack a charm without requires/provides relation in the metadata.yaml and create a relation after the charm is deployed (informing an arbitrary interface name)?
A follow up question: can we create a generic requires/provides relation interface name to relate one charm to different charms when deployed (these different charms would have different interface names)?
These questions are related to understand if we can create a generic tester charm to test our database operators relations without having to all the interfaces names in the metada.yaml (like a requires for postgresql interface, another for mongodb interface and so on).
I missed the beginning of this discussion and the conversation that followed was mainly about best practices …
But, in brief, you do not need to upload a .charm file to make a library available. You do need to charmcraft register a charm, but that charm can be a “ghost” charm that doesn’t do anything other than serve as a place to park your library.
I believe that the best way to publicize your library would be to create a topic page on this forum. I think that we’ll have more formal guidance around this coming very soon.
Note: there are some very legitimate questions about whether this actually represents a best practice. But if you wanted to do this, it is possible to do
