Version 0.8.0 of ops

framework
1

The charmcraft team is proud to announce that we’ve just released version 0.8.0 of ops, the Operator Framework for Juju charms.

Changes in this release 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.