This is version 0.10.0 of `ops`, the Operator Framework for Juju charms.

Changes include:

• deleting a non-existent key from relation data will no longer fail.
  Thanks to @stub42 for the fix.

• calling begin_with_initial_hooks() on the testing harness of a charm
  that has a relation that isn't set up before the call will no longer fail.
  Thanks to @zzehring for the fix.

• the testing harness now starts with default config values, specified in the
  same way as for actions.yaml and metadata.yaml (i.e. snippets if given,
  otherwise from the canonical yaml file).
  Thanks to @johnsca for the work.

• some classes now have custom __repr__ methods that should aid debugging.

• event deferral and reëmission is now logged (at DEBUG).

• if use_juju_for_storage is specified for a charm running in a Juju that does
  not support this feature, a clear and explicit error is raised.

• the public attributes of model are now immutable. This is to discourage
  people from overwriting these attributes in tests, given there is a fair
  amount of internal state. Please use the harness instead (or mocking if you
  must).

• the test suite now passes on Windows, and we run the full suite on Windows for
  every commit, as we do for linux and macos.

0.9.0 highlights:

Release highlights:

• Controller-side storage is now used automatically (i.e. without the
  charm author needing to set the use_juju_for_storage flag on
  main) when we're sure it's needed. It can still be forced on or
  off via that flag to main.

• A workaround for Juju's lp:1880637 to address #293, so
  pod.set_spec's k8s_resources works as expected. But note #387,
  as "as expected" might not be as you expect.

• If charm code is run in an environment that does not set
  JUJU_VERSION, default to 0.0.0 instead of raising an exception. This
  means all the feature checks will fail, but the charm can still
  progress. Please let us know if this is not what you want; this
  impacts #372.

• Charm authors can now use harness.hooks_disabled() as a context
  manager to run a block of code without events being fired for them.
  Without this you'd have to wrap that code in disable/enable
  pairs.

This is version 0.8.0 of `ops`, the Operator Framework for Juju charms.

Changes include:

• testing Harness updates

  • Harness.begin_with_initial_hooks() will cause the testing Harness to
    emit all of the events that Juju normally does while a charm is
    'starting'. (install, leader-elected, etc.). While most unit tests
    should be more focused on a single hook interaction, this gives a bit more
    confidence that the whole initialization step of the charm operates in a
    good manner.

  • Harness.get_pod_spec() allows a test to introspect what pod spec was set
    in response to their update event. Eg.,

    harness = Harness(MyCharm)
    # ... initial setup
    harness.begin()
    harness.update_config({'foo': 'bar'})
    pod_spec, k8s_resources = harness.get_pod_spec()
    self.assertIsNone(k8s_resources)
    self.assertEqual(pod_spec['blah']['blah'], 'bar')
    

  • Harness.cleanup() is now available to ensure that any temporary
    files/directories created by the harness are cleaned up. For unittest you
    would use this as:

    harness = Harness(MyCharm)
    self.addCleanup(harness.cleanup)
    ...
    

    This is currently only relevant if you are running tests that make use of
    resources (either add_oci_resource or add_resource). However, it is good
    practice to start making use of it, in case there are other resources
    associated with Harness that will need to be cleaned up.

  • Harness.add_resource() is now also available so that you can feed your
    charm code file content that it would get from resource-get.

• You no longer need to call ops.lib.autoimport before your first call to
  ops.lib.use; you only need to do it if the library information is out of
  date (e.g. if you installed or otherwise altered what the system would find).
  Also a lot more logging of the process of autodiscovery has been added.
  Thanks to @stub42 for pointing out how needing the first call was
  counter-intuitive, and the process hard to debug.

• Libraries used via ops.lib.use can now have subpackages or modules.

• dispatch-aware charms that set JUJU_DISPATCH_PATH before calling into the
  framework caused the framework to think the Juju it was running on supported
  dispatch, even if the version was clearly too old for that. This meant that
  non-initial hooks were never called on these charms on those
  Jujus. Unfortunately charms created with charmcraft 0.3 fell into this
  category. The framework now looks directly at the Juju version to determine
  dispatch support. Thanks to @gnuoy for finding reporting this.

0.7.0

0.7.0 release highlights:

• opt-in to test controller-side state via Juju 2.8's state-get/state-set (#317, #323)
• support for running on Juju pre-2.7 (#324)
• exceptions now logged via an ad-hoc excepthook (#322)
• performance improvement for large yaml blobs (#325)
• bug fixes :-)

0.6.1

• Fix a regression when running a non-dispatch-enabled charm on a dispatch-aware juju.
• Also a fix for status-get, which isn't a regression but has been deemed safe for a .1.

0.6.0

This is the first “official” release, and includes a few breaking changes from what was in master until very recently. From now on, breaking changes will be announced, and we’ll have a deprecation procedure to ease things in (or rather, out). These breaking changes are:

• The Framework object’s observe method’s second argument can no longer be an instance, and must be a method on an instance. That is, where previously you could write

  self.framework.observe(self.on.install, self)

  as a shortcut, but we found that this pushes people down a path that actually makes their charms less maintainable. Especially when it comes to writing components, it is better to have clearly named functions and clearly defined targets.

  So from now on the only supported way is to explicitly specify the callback method,

  self.framework.observe(self.on.install, self._on_install)

  (note we also recommend event handlers to be clearly marked as non-public).

• Relations' role attribute is now an enum, and in particular peer relation's role is now "peer" (it used to be "peers" which was just wrong).

This release includes full support for Juju 2.8's dispatch mechanism,including both use cases of dispatch being a symlink to the charm code, and dispatch being a small shim that executes the charm. The latter is an incremental improvement over what we mentioned in the last dev summary, and is already being used by charmcraft.

Lastly, Model objects now have a name property (populated from JUJU_MODEL_NAME). This was a feature requested by charmers.