Tags: benhoyt/operator
Tags
1.0.0 * We added quite a few docstrings, and a test that will fail if something is missing docstrings. * We're more tolerant of missing fields in the output of `network-get`, which can happen in some situations. Thanks to @johnsca for this one. * Charm authors can run `self.config` from a charm method instead of having to do `self.model.config`. Thanks to @johnsca for this one. * Some ways of installing `ops` can result in not loading the `libyaml` extensions from PyYAML, giving a performance penalty. `ops` will warn when this happens so it can be remedied, but it would also warn when running the test suite which raises the barrier for developers wanting to contribute to `ops` itself. So now we ignore that. Thanks to @johnsca for this one. * The `hooks_disabled` context manager can now be nested. Thanks to @stub42 for this one. * When using Juju for storage (either automatically by running on kubernetes with a new enough Juju, or manually via passing `use_juju_for_storage=True` to main), events defered would never be re-emitted. This is canonical#438, found with help from @davigar15. * ObjectEvents now have a `__repr__` which lists all events it knows about, which can be helpful when debugging (or even developing) a complex charm. * `sys.breakpointhook` is only set from `main`, not from `Framework.__init__`, meaning it won't interfere with using the `breakpoint()` builtin from tests. * tests will now fail if a docstring is missing (or malformed).
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: * 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 canonical#293, so `pod.set_spec`'s `k8s_resources` works as expected. But note canonical#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 canonical#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.
Tweaks to the README, setup.py, etc, for release. (canonical#305) * Tweaks to the README, setup.py, etc, for release.