Charmcraft Clinic

charmcraft
,
#1

Hello fellow charmers!

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.

8 Likes
#2

Added to the Charm Tech team’s calendar. I’ll definitely plan on being there!

3 Likes
#3

Is there an agenda for the first session?

1 Like
#4

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.

1 Like
#5

ah! I realised now (again) that UTC <> time in London now …

#6

This is the date using discourse’s date widget 2022-03-31T16:00:00Z → 2022-03-31T17:00:00Z

#7

There are 2 topics that I would like to discuss.

  • 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.

1 Like
#8

We are cancelling today’s clinic as it is a holiday in many places. Sorry for the late notice.

2 Likes
#9

And both April 28th and May 5th are cancelled too. An unavoidable meeting clashes with the former date, and the team will be busy on the later.

We’ll be back on May 12nd! Please annotate here below topics to talk about! See you :slight_smile:

1 Like
#10

Some topics that we can discuss today:

  • 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).