Operator Framework 1.5.0

announcements and community
,
1

The Operator Framework team is proud to release version 1.5.0 of the Operator Framework! This is a modestly sized release with a few new, non breaking features.

Highlights

  • Harness support for simulating storage mounts during testing - allowing disk IO to mounted filepaths and sharing data between shared mounts in charm and workload (via e.g. pebble operations) containers. This should “just work” - as long as you use the storage mount paths provided via e.g. self.model.storages['storage-name'][0].location which you should already be doing anyway (right?).
  • New Container.push_path and Container.pull_path methods for recursively pushing/pulling directories to/from workload containers.
  • We’ve begun to implement complete type annotations to improve auto-completion and robustness. Over the next release or so type annotation coverage will continue to improve.

Complete List of Changes

New Contributors

Full Changelog: https://github.com/canonical/operator/compare/1.4.0...1.5.0

3 Likes
2

Since 'storage-name' is runtime information obtained from metadata.yaml, I wonder how to handle the scenario someone renames a storage in metadata but forgets to update literals in charm code.

Let it raise KeyError and deal with it?

Add a “preconditions” section to __init__ that would show up in unit tests?

assert 'storage-name' in self.model.storages, "The 'storage-name' storage is no longer in metadata: must update literals in charm code."

Something else?

3

We already have a StorageMapping.__getitem__ where we could raise a fancier error message. We could even read the metadata storage names and say ... Did you mean "foo-storage"?.

4

That would be helpful for sure. There is still an unaddressed scenario though: StorageMapping.__getitem__ is called in a method that is not exercised / mocked in unit tests.

5

Let’s move discussion here.