From af94c83141bcd483dc5358014bcbd7265330fa4a Mon Sep 17 00:00:00 2001 From: Dave Wilding Date: Thu, 13 Feb 2025 13:18:43 +0800 Subject: [PATCH] Added intersphinx links to Juju (James did some in #1574 too) --- docs/howto/get-started-with-charm-testing.md | 2 +- docs/howto/manage-leadership-changes.md | 2 +- docs/howto/manage-logs.md | 2 +- docs/howto/manage-relations.md | 4 ++-- .../set-up-your-development-environment.md | 2 +- docs/tutorial/write-your-first-machine-charm.md | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/howto/get-started-with-charm-testing.md b/docs/howto/get-started-with-charm-testing.md index 95988b20e..216fb011a 100644 --- a/docs/howto/get-started-with-charm-testing.md +++ b/docs/howto/get-started-with-charm-testing.md @@ -167,7 +167,7 @@ def test_pebble_ready_writes_config_file(): ## Integration testing Where unit testing focuses on black-box method-by-method verification, integration testing focuses on the big picture. Typically integration tests check that the charm does not break (generally this means: blocks with status `blocked` or `error`) when a (mocked) cloud admin performs certain operations. These operations are scripted by using, in order of abstraction: - - shell commands against [the `juju` cli](https://juju.is/docs/olm/juju-cli-commands) + - shell commands against [the `juju` CLI](inv:juju:std:label#list-of-juju-cli-commands) - [`python-libjuju`](https://github.com/juju/python-libjuju), wrapping juju api calls - [`pytest-operator`](https://github.com/charmed-kubernetes/pytest-operator), a `pytest` plugin wrapping `python-libjuju` - [`zaza`](https://zaza.readthedocs.io/en/latest/index.html), a testing-framework-agnostic wrapper on top of `python-libjuju` diff --git a/docs/howto/manage-leadership-changes.md b/docs/howto/manage-leadership-changes.md index f7948bb02..6e7757f9b 100644 --- a/docs/howto/manage-leadership-changes.md +++ b/docs/howto/manage-leadership-changes.md @@ -25,7 +25,7 @@ def _on_leader_elected(self, event: ops.LeaderElectedEvent): To have the leader notify other units about leadership changes, change data in a peer relation. -> See more: [Peer Relations](https://juju.is/docs/juju/relation#heading--peer) +> See more: {external+juju:ref}`Juju | Peer relations ` [note status="Use the peer relation rather than `leader-setting-changed`"] In the past, this was done by observing a `leader-setting-changed` event, which is now deprecated. diff --git a/docs/howto/manage-logs.md b/docs/howto/manage-logs.md index 5afd26189..4164958cd 100644 --- a/docs/howto/manage-logs.md +++ b/docs/howto/manage-logs.md @@ -35,7 +35,7 @@ class HelloOperatorCharm(ops.CharmBase): > - [`logging.getLogger().info()`](https://docs.python.org/3/library/logging.html#logging.Logger.info) > - [`logging.getLogger().debug()`](https://docs.python.org/3/library/logging.html#logging.Logger.debug) -Juju automatically picks up logs from charm code that uses the Python [logging facility](https://docs.python.org/3/library/logging.html), so we can use the Juju [`debug-log` command](https://juju.is/docs/juju/juju-debug-log) to display logs for a model. Note that it shows logs from the charm code (charm container), but not the workload container. Read ["Use `juju debug-log`"](https://juju.is/docs/sdk/get-logs-from-a-kubernetes-charm#heading--use-juju-debug-log) for more information. +Juju automatically picks up logs from charm code that uses the Python [logging facility](https://docs.python.org/3/library/logging.html), so we can use the Juju [`debug-log` command](inv:juju:std:label#command-juju-debug-log) to display logs for a model. Note that it shows logs from the charm code (charm container), but not the workload container. Besides logs, `stderr` is also captured by Juju. So, if a charm generates a warning, it will also end up in Juju's debug log. This behaviour is consistent between K8s charms and machine charms. diff --git a/docs/howto/manage-relations.md b/docs/howto/manage-relations.md index 6198445a5..19e83bd1c 100644 --- a/docs/howto/manage-relations.md +++ b/docs/howto/manage-relations.md @@ -59,7 +59,7 @@ requires: Other than this, implement a subordinate relation in the same way as any other relation. Note however that subordinate units cannot see each other's peer data. -> See also: [Charm taxonomy](https://juju.is/docs/sdk/charm-taxonomy#heading--subordinate-charms) +> See also: {external+juju:ref}`Juju | Charm taxonomy ` ### Add code to use a relation @@ -123,7 +123,7 @@ To use data received through the relation, have your charm observe the `relation framework.observe(self.on.replicas_relation_changed, self._update_configuration) ``` -> See more: [](ops.RelationChangedEvent), [`juju` | Relation (integration)](https://juju.is/docs/juju/relation#heading--permissions-around-relation-databags) +> See more: [](ops.RelationChangedEvent), {external+juju:ref}`Juju | Relation (integration) ` Most of the time, you should use the same holistic handler as when receiving other data, such as `secret-changed` and `config-changed`. To access the relation(s) in your holistic handler, use the [](ops.Model.get_relation) method or [](ops.Model.relations) attribute. diff --git a/docs/tutorial/from-zero-to-hero-write-your-first-kubernetes-charm/set-up-your-development-environment.md b/docs/tutorial/from-zero-to-hero-write-your-first-kubernetes-charm/set-up-your-development-environment.md index 28046c2ba..304946eba 100644 --- a/docs/tutorial/from-zero-to-hero-write-your-first-kubernetes-charm/set-up-your-development-environment.md +++ b/docs/tutorial/from-zero-to-hero-write-your-first-kubernetes-charm/set-up-your-development-environment.md @@ -11,7 +11,7 @@ You will need a charm directory, the various tools in the charm SDK, Juju, and a You can get all of this by following our generic development setup guide, with some annotations. -> See [Set up / tear down automatically](https://juju.is/docs/juju/set-up--tear-down-your-test-environment#set-up-tear-down-automatically), with the following changes: +> See the automatic setup instructions in {external+juju:ref}`Juju | Manage your deployment environment `, with the following changes: > - At the directory step, call your directory `fastapi-demo`. > - At the VM setup step, call your VM `charm-dev` and also set up Docker: > 1. `sudo addgroup --system docker` diff --git a/docs/tutorial/write-your-first-machine-charm.md b/docs/tutorial/write-your-first-machine-charm.md index 772140490..f630f3fb7 100644 --- a/docs/tutorial/write-your-first-machine-charm.md +++ b/docs/tutorial/write-your-first-machine-charm.md @@ -522,7 +522,7 @@ Congratulations, your charm user can view the version of the workload deployed f ## Tear things down -> See [Juju | Tear down your development environment automatically](https://juju.is/docs/juju/set-up--tear-down-your-test-environment#tear-down-automatically) +> See the automatic teardown instructions in {external+juju:ref}`Juju | Manage your deployment environment `.