ops 2.22.0__tar.gz → 2.23.0.dev0__tar.gz

ops-2.23.0.dev0/CONTRIBUTING.md

@@ -0,0 +1,130 @@
+We welcome contributions to Ops!
+
+Before working on changes, please consider [opening an issue](https://github.com/canonical/operator/issues) explaining your use case. If you would like to chat with us about your use cases or proposed implementation, you can reach us at [Matrix](https://matrix.to/#/#charmhub-charmdev:ubuntu.com) or [Discourse](https://discourse.charmhub.io/).
+
+For detailed technical information about the development of Ops, see [HACKING.md](./HACKING.md).
+
+# Pull requests
+
+Changes are proposed as [pull requests on GitHub](https://github.com/canonical/operator/pulls).
+
+Pull requests should have a short title that follows the [conventional commit style](https://www.conventionalcommits.org/en/) using one of these types:
+
+- chore
+- ci
+- docs
+- feat
+- fix
+- perf
+- refactor
+- revert
+- test
+
+Some examples:
+
+- feat: add the ability to observe change-updated events
+- fix!: correct the type hinting for config data
+- docs: clarify how to use mounts in ops.testing.Container
+- ci: adjust the workflow that publishes ops-scenario
+
+We consider Ops too small a project to use scopes, so we don't use them.
+
+Note that the commit messages to the PR's branch do not need to follow the conventional commit format, as these will be squashed into a single commit to `main` using the PR title as the commit message.
+
+To help us review your changes, please rebase your pull request onto the `main` branch before you request a review. If you need to bring in the latest changes from `main` after the review has started, please use a merge commit.
+
+# Tests
+
+Changes should include tests. Where reasonable, prefer to write 'Scenario' tests using [ops.testing](https://ops.readthedocs.io/en/latest/reference/ops-testing.html) instead of legacy [ops.testing.Harness](https://ops.readthedocs.io/en/latest/reference/ops-testing-harness.html) tests.
+
+Tests for Ops should go in the test module corresponding to the code. For example, a feature added in `ops/main.py` would go in `test/test_main.py`. However, when adding a large number of logically related tests, consider putting these in their own file, named accordingly. For example, if adding a feature `foo` in `ops/main.py`, the tests might go in `test/test_main_foo.py`.
+
+Tests for [`ops-scenario`](https://github.com/canonical/operator/tree/main/testing/tests) and [`ops-tracing`](https://github.com/canonical/operator/tree/main/tracing/test) are arranged differently in places. Try to find the most logical place to add tests, based on the code that is tested.
+
+# Coding style
+
+We have a team [Python style guide](./STYLE.md), most of which is enforced by CI checks. Please be complete with docstrings and keep them informative for _users_, as the [Ops library reference](https://ops.readthedocs.io/en/latest/reference/index.html) is automatically generated from Python docstrings.
+
+# Documentation
+
+The published docs at [ops.readthedocs.io](https://ops.readthedocs.io/en/latest/index.html) are built automatically from [the top-level `docs` directory](./docs). We use [MyST Markdown](https://mystmd.org/) for most pages and arrange the pages according to [Diátaxis](https://diataxis.fr/).
+
+To contribute docs:
+
+1. Fork this repo and edit the relevant source files:
+    - Tutorials - [`/docs/tutorial`](./docs/tutorial)
+    - How-to guides - [`/docs/howto`](./docs/howto)
+    - Reference - Automatically generated from Python docstrings
+    - Explanation - [`/docs/explanation`](./docs/explanation)
+2. [Build the documentation locally](#how-to-build-the-documentation-locally), to check that everything looks right
+3. [Propose your changes using a pull request](#pull-requests)
+
+When you create the pull request, GitHub automatically builds a preview of the docs. To find the preview, look for the "docs/readthedocs.org:ops" check near the bottom of the pull request page, then click **Details**. You can use the preview to double check that everything looks right.
+
+## How to write great documentation
+
+- Use short sentences, ideally with one or two clauses.
+- Use headings to split the doc into sections. Make sure that the purpose of each section is clear from its heading.
+- Avoid a long introduction. Assume that the reader is only going to scan the first paragraph and the headings.
+- Avoid background context unless it's essential for the reader to understand.
+
+Recommended tone:
+
+- Use a casual tone, but avoid idioms. Common contractions such as "it's" and "doesn't" are great.
+- Use "we" to include the reader in what you're explaining.
+- Avoid passive descriptions. If you expect the reader to do something, give a direct instruction.
+
+## How to build the documentation locally
+
+To build the docs and open them in your browser:
+
+```sh
+tox -e docs
+open docs/_build/html/index.html
+```
+
+Alternatively, to serve the docs locally and automatically refresh them whenever you edit a file:
+
+```sh
+tox -e docs-live
+```
+
+## How to document version dependencies
+
+We don't publish separate documentation for separate versions of Ops. The published docs at [ops.readthedocs.io](https://ops.readthedocs.io/en/latest/index.html) are always for the in-development (main branch) of Ops, and do not include any notes indicating changes or additions across Ops versions. We encourage all charmers to promptly upgrade to the latest version of Ops, and to refer to the release notes and changelog for learning about changes.
+
+We do note when features behave differently when using different versions of Juju.
+
+In docstrings:
+
+- Use `.. jujuadded:: x.y` to indicate that the feature is only available when using version x.y (or higher) of Juju.
+- Use `.. jujuchanged:: x.y` when the feature's behaviour _in Ops_ changes.
+- Use `.. jujuremoved:: x.y` when the feature will be available in Ops but not in that version (or later) of Juju.
+
+Similar directives also work in MyST Markdown. For example:
+
+````markdown
+```{jujuadded} x.y
+Summary
+```
+````
+
+Unmarked features are assumed to work and be available in the current LTS version of Juju.
+
+# Copyright
+
+The format for copyright notices is documented in the [LICENSE.txt](LICENSE.txt). New files should begin with a copyright line with the current year (e.g. Copyright 2024 Canonical Ltd.) and include the full boilerplate (see APPENDIX of [LICENSE.txt](LICENSE.txt)). The copyright information in existing files does not need to be updated when those files are modified -- only the initial creation year is required.
+
+# Reviews
+
+All changes require review before being merged. Code review typically examines:
+
+- Code quality
+- Test coverage
+- User experience
+
+When evaluating design decisions, we give priority to the following personas:
+
+- Charm authors and maintainers (highest priority)
+- Contributors to the Ops codebase
+- Juju developers

{ops-2.22.0 → ops-2.23.0.dev0}/HACKING.md

@@ -1,14 +1,38 @@
+We welcome contributions to Ops! Before you start work on a contribution, please also read [CONTRIBUTING.md](./CONTRIBUTING.md).
+
 # Setting up a Dev Environment
 
 To work in the framework itself you will need Python >= 3.8. Linting, testing,
 and docs automation is performed using
-[`tox`](https://tox.readthedocs.io/en/latest/), which you should install.
-For improved performance on the tests, ensure that you have PyYAML
-installed with the correct extensions:
+[`tox`](https://tox.readthedocs.io/en/latest/).
+
+First, make sure to install [uv](https://docs.astral.sh/uv/), for example:
+
+```sh
+sudo snap install astral-uv --classic
+```
+
+Then install `tox` with extensions, as well as a range of Python versions:
 
 ```sh
-apt-get install libyaml-dev
-pip install --force-reinstall --no-cache-dir pyyaml
+uv tool install tox --with tox-uv
+uv tool update-shell
+```
+
+You can validate that you have a working installation by running:
+
+```sh
+tox --version
+4.26.0 from /home/<your-user>/.local/share/uv/tools/tox/lib/python3.13/site-packages/tox/__init__.py
+registered plugins:
+    tox-uv-1.26.0 at /home/<your-user>/.local/share/uv/tools/tox/lib/python3.13/site-packages/tox_uv/plugin.py with uv==0.7.12
+```
+
+For improved performance on the tests, install the library that allows
+PyYAML to use C speedups:
+
+```sh
+sudo apt-get install libyaml-dev
 ```
 
 # Testing
@@ -26,9 +50,6 @@ tox -e unit -- test/test_charm.py
 # Format the code using Ruff
 tox -e format
 
-# Compile the requirements.txt file for docs
-tox -e docs-deps
-
 # Generate a local copy of the Sphinx docs in docs/_build
 tox -e docs
 
@@ -36,23 +57,18 @@ tox -e docs
 tox -e unit -- -k <pattern>
 ```
 
-For more in depth debugging, you can enter any of `tox`'s created virtualenvs
-provided they have been run at least once and do fun things - e.g. run
-`pytest` directly:
+For more in depth debugging, you can enter the virtualenv so that you can run
+`pytest` or other tools directly:
 
 ```sh
-# Enter the linting virtualenv
-source .tox/lint/bin/activate
-
-...
-
-# Enter the unit testing virtualenv and run tests
-source .tox/unit/bin/activate
+uv sync --all-groups
+source .venv/bin/activate
 pytest
-...
-
 ```
 
+Likewise, use this virtualenv to enable Python type hints and language server if
+you use an editor from the console or specify it as interpreter path in an IDE.
+
 ## Pebble Tests
 
 The framework has some tests that interact with a real/live Pebble server.  To
@@ -160,126 +176,6 @@ your charm to a controller using that version of Juju. For example, with microk8
 We rely on automation to [update charm pins](.github/actions/update-charm-pins/) of
 a bunch of charms that use the operator framework. The script can be run locally too.
 
-# Contributing
-
-Changes are proposed as [pull requests on GitHub](https://github.com/canonical/operator/pulls).
-
-For coding style, we follow [PEP 8](https://peps.python.org/pep-0008/) as well as a team [Python style guide](./STYLE.md). Please be complete with docstrings and keep them informative for _users_,
-as the [ops library reference](https://ops.readthedocs.io/en/latest/reference/index.html)
-is automatically generated from Python docstrings.
-
-For more advice about contributing documentation, see [Contributing documentation](#contributing-documentation).
-
-Pull requests should have a short title that follows the
-[conventional commit style](https://www.conventionalcommits.org/en/) using one of these types:
-
-* chore
-* ci
-* docs
-* feat
-* fix
-* perf
-* refactor
-* revert
-* test
-
-Some examples:
-
-* feat: add the ability to observe change-updated events
-* fix!: correct the type hinting for config data
-* docs: clarify how to use mounts in ops.testing.Container
-* ci: adjust the workflow that publishes ops-scenario
-
-Note that the commit messages to the PR's branch do not need to follow the
-conventional commit format, as these will be squashed into a single commit to `main`
-using the PR title as the commit message.
-
-We consider Ops too small a project to use scopes, so we don't use them.
-
-## Copyright
-
-The format for copyright notices is documented in the [LICENSE.txt](LICENSE.txt).
-New files should begin with a copyright line with the current year (e.g. Copyright 2024 Canonical Ltd.) and include the full boilerplate (see APPENDIX of [LICENSE.txt](LICENSE.txt)).
-The copyright information in existing files does not need to be updated when those files are modified -- only the initial creation year is required.
-
-# Contributing documentation
-
-The published docs at [ops.readthedocs.io](https://ops.readthedocs.io/en/latest/index.html)
-are built automatically from [the top-level `docs` directory](./docs). We use [MyST Markdown](https://mystmd.org/)
-for most pages and arrange the pages according to [Diátaxis](https://diataxis.fr/).
-
-To contribute docs:
-
-1. Fork this repo and edit the relevant source files:
-   * Tutorials - [`/docs/tutorial`](./docs/tutorial)
-   * How-to guides - [`/docs/howto`](./docs/howto)
-   * Reference - Automatically generated from Python docstrings
-   * Explanation - [`/docs/explanation`](./docs/explanation)
-2. [Build the documentation locally](#how-to-build-the-documentation-locally),
-   to check that everything looks right
-3. [Propose your changes using a pull request](#contributing)
-
-When you create the pull request, GitHub automatically builds a preview of the docs.
-To find the preview, look for the "docs/readthedocs.org:ops" check near the bottom of
-the pull request page, then click **Details**. You can use the preview to double check
-that everything looks right.
-
-## How to write great documentation
-
-- Use short sentences, ideally with one or two clauses.
-- Use headings to split the doc into sections. Make sure that the purpose of each section is clear from its heading.
-- Avoid a long introduction. Assume that the reader is only going to scan the first paragraph and the headings.
-- Avoid background context unless it's essential for the reader to understand.
-
-Recommended tone:
-- Use a casual tone, but avoid idioms. Common contractions such as "it's" and "doesn't" are great.
-- Use "we" to include the reader in what you're explaining.
-- Avoid passive descriptions. If you expect the reader to do something, give a direct instruction.
-
-## How to build the documentation locally
-
-To build the docs and open them in your browser:
-
-```sh
-tox -e docs
-open docs/_build/html/index.html
-```
-
-Alternatively, to serve the docs locally and automatically refresh them whenever you edit a file:
-
-```sh
-tox -e docs-live
-```
-
-## How to document version dependencies
-
-We don't publish separate documentation for separate versions of ops.
-The published docs at [ops.readthedocs.io](https://ops.readthedocs.io/en/latest/index.html)
-are always for the in-development (main branch) of ops, and do not include
-any notes indicating changes or additions across ops versions.
-We encourage all charmers to promptly upgrade to the latest version of ops,
-and to refer to the release notes and changelog for learning about changes.
-
-We do note when features behave differently when using different versions of Juju.
-
-In docstrings:
-
-* Use `.. jujuadded:: x.y` to indicate that the feature is only available
-  when using version x.y (or higher) of Juju.
-* Use `..jujuchanged:: x.y` when the feature's behaviour _in ops_ changes.
-* Use `..jujuremoved:: x.y` when the feature will be available in ops
-  but not in that version (or later) of Juju.
-
-Similar directives also work in MyST Markdown. For example:
-
-````markdown
-```{jujuadded} x.y
-Summary
-```
-````
-
-Unmarked features are assumed to work and be available in the current LTS version of Juju.
-
 # Maintaining the documentation
 
 ## How to Pull in Style Changes
@@ -307,7 +203,7 @@ To pull in new dependency changes from the starter pack, change to the starter p
 make html
 ```
 
-Then, compare the generated file `.sphinx/requirements.txt`and the `project.optional-dependencies.docs` section of [`pyproject.toml`](./pyproject.toml) and adjust the `pyproject.toml` file accordingly.
+Then, compare the generated file `.sphinx/requirements.txt` and the `docs` declaration in the `dependency-groups` section of [`pyproject.toml`](./pyproject.toml) and adjust the `pyproject.toml` file accordingly.
 
 # Dependencies
 
@@ -368,14 +264,11 @@ To make a release of the `ops` and/or `ops-scenario` packages, do the following:
     - in [pyroject.toml for `ops`](pyproject.toml), the required versions for `ops-scenario` and `ops-tracing`
     - in [pyproject.toml for `ops-scenario`](testing/pyproject.toml), the `version` attribute and the required version for `ops`
     - in [pyproject.toml for `ops-tracing`](tracing/pyproject.toml), the `version` attribute and the required version for `ops`
-11. Run `uvx -p 3.11 tox -e docs-deps` to recompile the `requirements.txt` file
-   used for docs (in case dependencies have been updated in `pyproject.toml`)
-   using the same Python version as specified in the `.readthedocs.yaml` file.
-12. Add, commit, and push, and open a PR to get the `CHANGES.md` update, version bumps,
-   and doc requirement bumps into main (and get it merged).
-13. Wait until the tests pass after the PR is merged. It takes around 10 minutes.
+11. Add, commit, and push, and open a PR to get the `CHANGES.md` update and version
+   bumps into main (and get it merged).
+12. Wait until the tests pass after the PR is merged. It takes around 10 minutes.
    If the tests don't pass at the tip of the main branch, do not release.
-14. When you are ready, click "Publish". GitHub will create the additional tag.
+13. When you are ready, click "Publish". GitHub will create the additional tag.
 
     Pushing the tags will trigger automatic builds for the Python packages and
     publish them to PyPI ([ops](https://pypi.org/project/ops/) and
@@ -388,9 +281,9 @@ To make a release of the `ops` and/or `ops-scenario` packages, do the following:
     (Note that the versions in the YAML refer to versions of the GitHub actions, not the versions of the ops  library.)
 
     You can troubleshoot errors on the [Actions Tab](https://github.com/canonical/operator/actions).
-15. Announce the release on [Discourse](https://discourse.charmhub.io/c/framework/42)
+14. Announce the release on [Discourse](https://discourse.charmhub.io/c/framework/42)
     and [Matrix](https://matrix.to/#/#charmhub-charmdev:ubuntu.com).
-16. Open a PR to change the version strings to the expected next version, with ".dev0" appended.
+15. Open a PR to change the version strings to the expected next version, with ".dev0" appended.
    For example, if 2.90.0 is the next expected `ops` version, use
    `ops==2.90.0.dev0 ops-tracing==2.90.0.dev0 ops-scenario==7.90.0.dev0`.
    There will be a total of seven changes:

{ops-2.22.0 → ops-2.23.0.dev0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ops
-Version: 2.22.0
+Version: 2.23.0.dev0
 Summary: The Python library behind great charms
 Author: The Charm Tech team at Canonical Ltd.
 Project-URL: Homepage, https://ops.readthedocs.io/en/latest/
@@ -22,24 +22,10 @@ Requires-Dist: PyYAML==6.*
 Requires-Dist: websocket-client==1.*
 Requires-Dist: opentelemetry-api~=1.0
 Requires-Dist: importlib-metadata
-Provides-Extra: docs
-Requires-Dist: canonical-sphinx-extensions; extra == "docs"
-Requires-Dist: furo; extra == "docs"
-Requires-Dist: linkify-it-py; extra == "docs"
-Requires-Dist: myst-parser; extra == "docs"
-Requires-Dist: pyspelling; extra == "docs"
-Requires-Dist: sphinx~=8.0.0; extra == "docs"
-Requires-Dist: sphinx-autobuild; extra == "docs"
-Requires-Dist: sphinx-copybutton; extra == "docs"
-Requires-Dist: sphinx-design; extra == "docs"
-Requires-Dist: sphinx-notfound-page; extra == "docs"
-Requires-Dist: sphinx-tabs; extra == "docs"
-Requires-Dist: sphinxcontrib-jquery; extra == "docs"
-Requires-Dist: sphinxext-opengraph; extra == "docs"
 Provides-Extra: testing
-Requires-Dist: ops-scenario==7.22.0; extra == "testing"
+Requires-Dist: ops-scenario==7.23.0.dev0; extra == "testing"
 Provides-Extra: tracing
-Requires-Dist: ops-tracing==2.22.0; extra == "tracing"
+Requires-Dist: ops-tracing==2.23.0.dev0; extra == "tracing"
 Provides-Extra: harness
 Dynamic: license-file
 
@@ -131,46 +117,48 @@ class OpsExampleCharm(ops.CharmBase):
         self.unit.status = ops.ActiveStatus()
 ```
 
-> See more: [`ops.PebbleReadyEvent`](https://ops.readthedocs.io/en/latest/index.html#ops.PebbleReadyEvent)
+> See more: [`ops.PebbleReadyEvent`](https://ops.readthedocs.io/en/latest/reference/ops.html#ops.PebbleReadyEvent)
 
-- The `tests/unit/test_charm.py` file imports `ops.testing` and uses it to set up a testing harness:
+- The `tests/unit/test_charm.py` file imports `ops.testing` and uses it to set up a unit test:
 
 ```python
-import ops.testing
-
-class TestCharm(unittest.TestCase):
-    def setUp(self):
-        self.harness = ops.testing.Harness(OpsExampleCharm)
-        self.addCleanup(self.harness.cleanup)
-        self.harness.begin()
-
-    def test_httpbin_pebble_ready(self):
-        # Expected plan after Pebble ready with default config
-        expected_plan = {
-            "services": {
-                "httpbin": {
-                    "override": "replace",
-                    "summary": "httpbin",
-                    "command": "gunicorn -b 0.0.0.0:80 httpbin:app -k gevent",
-                    "startup": "enabled",
-                    "environment": {"GUNICORN_CMD_ARGS": "--log-level info"},
-                }
-            },
-        }
-        # Simulate the container coming up and emission of pebble-ready event
-        self.harness.container_pebble_ready("httpbin")
-        # Get the plan now we've run PebbleReady
-        updated_plan = self.harness.get_container_pebble_plan("httpbin").to_dict()
-        # Check we've got the plan we expected
-        self.assertEqual(expected_plan, updated_plan)
-        # Check the service was started
-        service = self.harness.model.unit.get_container("httpbin").get_service("httpbin")
-        self.assertTrue(service.is_running())
-        # Ensure we set an ActiveStatus with no message
-        self.assertEqual(self.harness.model.unit.status, ops.ActiveStatus())
+import ops
+from ops import testing
+
+from charm import OpsExampleCharm
+
+
+def test_httpbin_pebble_ready():
+    # Arrange:
+    ctx = testing.Context(OpsExampleCharm)
+    container = testing.Container("httpbin", can_connect=True)
+    state_in = testing.State(containers={container})
+
+    # Act:
+    state_out = ctx.run(ctx.on.pebble_ready(container), state_in)
+
+    # Assert:
+    updated_plan = state_out.get_container(container.name).plan
+    expected_plan = {
+        "services": {
+            "httpbin": {
+                "override": "replace",
+                "summary": "httpbin",
+                "command": "gunicorn -b 0.0.0.0:80 httpbin:app -k gevent",
+                "startup": "enabled",
+                "environment": {"GUNICORN_CMD_ARGS": "--log-level info"},
+            }
+        },
+    }
+    assert expected_plan == updated_plan
+    assert (
+        state_out.get_container(container.name).service_statuses["httpbin"]
+        == ops.pebble.ServiceStatus.ACTIVE
+    )
+    assert state_out.unit_status == testing.ActiveStatus()
 ```
 
-> See more: [`ops.testing.Harness`](https://ops.readthedocs.io/en/latest/#ops.testing.Harness)
+> See more: [`ops.testing`](https://ops.readthedocs.io/en/latest/reference/ops-testing.html)
 
 
 Explore further, start editing the files, or skip ahead and pack the charm:

{ops-2.22.0 → ops-2.23.0.dev0}/README.md

@@ -86,46 +86,48 @@ class OpsExampleCharm(ops.CharmBase):
         self.unit.status = ops.ActiveStatus()
 ```
 
-> See more: [`ops.PebbleReadyEvent`](https://ops.readthedocs.io/en/latest/index.html#ops.PebbleReadyEvent)
+> See more: [`ops.PebbleReadyEvent`](https://ops.readthedocs.io/en/latest/reference/ops.html#ops.PebbleReadyEvent)
 
-- The `tests/unit/test_charm.py` file imports `ops.testing` and uses it to set up a testing harness:
+- The `tests/unit/test_charm.py` file imports `ops.testing` and uses it to set up a unit test:
 
 ```python
-import ops.testing
-
-class TestCharm(unittest.TestCase):
-    def setUp(self):
-        self.harness = ops.testing.Harness(OpsExampleCharm)
-        self.addCleanup(self.harness.cleanup)
-        self.harness.begin()
-
-    def test_httpbin_pebble_ready(self):
-        # Expected plan after Pebble ready with default config
-        expected_plan = {
-            "services": {
-                "httpbin": {
-                    "override": "replace",
-                    "summary": "httpbin",
-                    "command": "gunicorn -b 0.0.0.0:80 httpbin:app -k gevent",
-                    "startup": "enabled",
-                    "environment": {"GUNICORN_CMD_ARGS": "--log-level info"},
-                }
-            },
-        }
-        # Simulate the container coming up and emission of pebble-ready event
-        self.harness.container_pebble_ready("httpbin")
-        # Get the plan now we've run PebbleReady
-        updated_plan = self.harness.get_container_pebble_plan("httpbin").to_dict()
-        # Check we've got the plan we expected
-        self.assertEqual(expected_plan, updated_plan)
-        # Check the service was started
-        service = self.harness.model.unit.get_container("httpbin").get_service("httpbin")
-        self.assertTrue(service.is_running())
-        # Ensure we set an ActiveStatus with no message
-        self.assertEqual(self.harness.model.unit.status, ops.ActiveStatus())
+import ops
+from ops import testing
+
+from charm import OpsExampleCharm
+
+
+def test_httpbin_pebble_ready():
+    # Arrange:
+    ctx = testing.Context(OpsExampleCharm)
+    container = testing.Container("httpbin", can_connect=True)
+    state_in = testing.State(containers={container})
+
+    # Act:
+    state_out = ctx.run(ctx.on.pebble_ready(container), state_in)
+
+    # Assert:
+    updated_plan = state_out.get_container(container.name).plan
+    expected_plan = {
+        "services": {
+            "httpbin": {
+                "override": "replace",
+                "summary": "httpbin",
+                "command": "gunicorn -b 0.0.0.0:80 httpbin:app -k gevent",
+                "startup": "enabled",
+                "environment": {"GUNICORN_CMD_ARGS": "--log-level info"},
+            }
+        },
+    }
+    assert expected_plan == updated_plan
+    assert (
+        state_out.get_container(container.name).service_statuses["httpbin"]
+        == ops.pebble.ServiceStatus.ACTIVE
+    )
+    assert state_out.unit_status == testing.ActiveStatus()
 ```
 
-> See more: [`ops.testing.Harness`](https://ops.readthedocs.io/en/latest/#ops.testing.Harness)
+> See more: [`ops.testing`](https://ops.readthedocs.io/en/latest/reference/ops-testing.html)
 
 
 Explore further, start editing the files, or skip ahead and pack the charm: