charmcraft team mailing list archive

[John Lenton <chipaca@xxxxxxxxxxxxx>]

Ops (the operator framework itself)

   - We released 0.6.1 <https://pypi.org/project/ops/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
   <https://github.com/canonical/operator/releases/tag/0.6.1> 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
   <https://github.com/canonical/operator/blob/master/CODE_OF_CONDUCT.md>,
   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.

Charmcraft

   - We released 0.1.2 <https://pypi.org/project/charmcraft/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
   <https://github.com/canonical/charmcraft/blob/master/CODE_OF_CONDUCT.md>
   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.

Chatting…

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.