Charmcraft bi-Weekly Dev Summary - 2020w23,24

prev (w21,22)

Ops (the operator framework itself)

  • We released 0.6.1 to fix a bug when running a non-dispatch-aware charm on a dispatch-aware Juju, that we considered a regression. It also includes a non-regression fix for status-get. The github release page has a bit more detail, but it also has tarballs which won’t quite work yet. We’ve changed things around in our release process to address this and 0.7 should have immediately useful attachments on github.
  • We incorporated a Code of Conduct, based off of the Contributor Covenant 1.4 (the same one snapd and snapcraft use).
  • The initial pass of using Juju 2.8’s new state-get and state-set to save the state of the charm and framework in the Juju controller rather than relying on reliable disk access is well under way, and on track for 0.7 (at the end of the month).
  • Also in 0.7 will be a change that’s already on master that enables running operator charms on Juju versions prior to 2.7.


  • We released 0.1.2, which fixes an issue when running a dispatch-aware charm on a non-dispatch-aware Juju (are you seeing a pattern here). It’s not 0.1.1 because of some early testing with pypi done by yours truly unwittingly blocking that release.
  • We incorporated the same Code of Conduct as ops itself.
  • At our architect’s request we’re slowing development on charmcraft while writing specs for its expected behaviour for him to review.
  • We’re also working with our Design team to ensure the UX of charmcraft is aligned with the rest of our command-line suite of tools.
  • 0.2 is still planned for end-of-month, to include a barebones store interaction; the right UX and etc. will come in a later release.


Our conversations these past two weeks have gone from chatting about using the operator framework, to actively reviewing charm code. As well as providing direct feedback on the charms and components we review, we’re using these reviews to assemble a document about what we look for in high-quality charms and components. We’ve also identified a couple of commonly-reused components and have started pulling out one of them to use via ops.lib.use.

next (w25,26)
1 Like