You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: fill out remaining external link placeholders (#1564)
All the remaining "UPDATE LINKS" notes in the docs are replaced with
actual links to the external Juju/Charmcraft docs.
Also changes the "product page" to be `juju.is` rather than
`juju.is/docs/sdk` as the latter is going away (`juju.is` was
recommended by @tmihoc).
(These changes were previously in [a commit in another
PR](tmihoc@54dca52) but got lost when
changes were forced - it seemed cleanest to break them out into a
separate PR).
Copy file name to clipboardExpand all lines: docs/explanation/storedstate-uses-limitations.md
+3-9Lines changed: 3 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -7,9 +7,7 @@
7
7
8
8
This is an explanatory doc covering how charm authors might track local state in a Juju unit. We'll cover the `ops` concept of [](ops.StoredState), along with some differences in how it works between machine charms and Kubernetes charms. We'll talk about Peer Relations as an alternative for storing some kinds of information, and also talk about how charm authors probably should avoid recording state when they can avoid doing so.
9
9
10
-
<!-- UPDATE LINKS
11
-
"Peer Relations", above
12
-
-->
10
+
> See more: {external+juju:ref}`Peer Relations <manage-relations>`
In the other cases where state is needed, authors ideally want to relate a charm to a database, attach storage (see Juju storage), or simply be opinionated, and hard code the single "correct" state into the charm. (Perhaps `ExampleBlog` should always be run in`production` mode when deployed as a charm?)
109
107
110
-
<!--UPDATELINKS
111
-
"Juju Storage" above
112
-
-->
108
+
> See more: {external+juju:ref}`Juju Storage <manage-storage>`
113
109
114
110
In the cases where it is important to share some lightweight configuration data between units of an application, charm author's should look into peer relations. And in the cases where data must be written to a container's local file system (Canonical's Kubeflow bundle, for example, must do this, because the sheer number of services mean that we run into limitations on attached storage in the underlying cloud), authors should do so mindfully, with an understanding of the pitfalls involved.
115
111
116
-
<!--UPDATELINKS
117
-
"peer relations", above
118
-
-->
112
+
> See more: {external+juju:ref}`Peer Relations <manage-relations>`
119
113
120
114
In sum: use state mindfully, with well chosen tools, only when necessary.
Copy file name to clipboardExpand all lines: docs/howto/get-started-with-charm-testing.md
-4Lines changed: 0 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -77,10 +77,6 @@ If the charm is a machine charm, workload operation calls can be done directly,
77
77
78
78
"Juju operations" are the most 'meta' of them all: they do not affect the workload in and of itself, but they share data which is meant to affect the operation of *other* charms that this charm is integrated with.
79
79
80
-
<!-- UPDATE LINKS:
81
-
> See more: [Talking to a workload: control flow from A to Z](), [Charm lifecycle]()
82
-
-->
83
-
84
80
### What we are testing when we unit-test
85
81
86
82
A 'live', deployed Juju application will have access to all the inputs we discussed above, including environment variables, host system access, and more. Unit tests will typically want to mock all that and focus on mapping inputs to expected outputs. Any combination of the input sources we mentioned above can result in any combination of operations. A few examples of increasing complexity of scenarios we may want to unit test:
@@ -280,15 +274,12 @@ Using the new alias, you can switch context to the new created model, similar to
280
274
281
275
> Example implementations: [`charm-kubernetes-autoscaler`](https://github.com/charmed-kubernetes/charm-kubernetes-autoscaler/blob/8f4ddf5d66802ade73ed3aab2bb8d09fd9e4d63a/tests/integration/test_kubernetes_autoscaler.py#L31)
0 commit comments