Skip to content

Commit 0ec4250

Browse files
committed
Doc for opt-in propagation mode
Addresses issue kubernetes-retired#221, documentation is added on the `AllowPropagate` sync mode and on the `all` selector. Signed-off-by: mzeevi <[email protected]>
1 parent ec50308 commit 0ec4250

File tree

2 files changed

+47
-13
lines changed

2 files changed

+47
-13
lines changed

docs/user-guide/concepts.md

Lines changed: 16 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -319,10 +319,10 @@ application.
319319
for policy purposes.*
320320

321321
<a name="basic-exceptions"/>
322-
322+
323323
### Exceptions and propagation control
324324

325-
By default, HNC propagates _all_ objects of a [specified type](how-to.md#admin-resources)
325+
HNC typically propagates _all_ objects of a [specified type](how-to.md#admin-resources)
326326
from ancestor namespaces to descendant namespaces. However, sometimes this is
327327
too restrictive, and you need to create ***exceptions*** to certain policies. For example:
328328

@@ -352,6 +352,20 @@ overwritten by your actions. You can then rewrite the exception to safely
352352
exclude those objects, or else delete the conflicting objects to allow them to
353353
be replaced.
354354

355+
#### (Beta in v1.1) Opt-in propagation
356+
The `Propagate` mode propagates all objects unless directed to otherwise via a selector,
357+
using exceptions. By contrast, opt-in propagation, as set by the `AllowPropagate`
358+
mode, doesn't propagate objects unless directed to by a selector. That is, for an object
359+
with a selector, its behaviour will be identical in both the `Propagate` and `AllowPropagate` modes;
360+
the only difference in behaviours is for objects without a selector.
361+
362+
For example:
363+
364+
* A Secret exists on a namespace but we don't want this secret to be propagated
365+
to all subnamespaces by default but instead only to one namespace of our choosing.
366+
So you can choose to propagate to that _one_ child namespace using `AllowPropagate`
367+
and exceptions.
368+
355369
#### Built-in exceptions
356370

357371
There are some built-in exceptions to prevent certain known (auto-generated)

docs/user-guide/how-to.md

Lines changed: 31 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -366,7 +366,17 @@ can use any of the following annotations:
366366

367367
* **`propagate.hnc.x-k8s.io/none`**: Setting `none` to `true` (case insensitive)
368368
will result in the object not propagating to _any_ descendant namespace. Any
369-
other value will be rejected.
369+
other value will be rejected. This is only useful in `Propagate`
370+
[synchronization mode](#modify-the-resources-propagated-by-hnc).
371+
372+
* **`propagate.hnc.x-k8s.io/all`**: Setting `all` to `true` (case insensitive)
373+
will result in the object propagating to _any_ descendant namespace. Any
374+
other value will be rejected. This is only useful in `AllowPropagate`
375+
[synchronization mode](#modify-the-resources-propagated-by-hnc).
376+
377+
Warning: only use one of the propagation annotations on any one object at a time.
378+
Interactions between multiple propagation annotations is undefined and may change
379+
from release to release.
370380

371381
For example, consider a case with a parent namespace with three child
372382
namespaces, and the parent namespace has a secret called `my-secret`. To set
@@ -382,12 +392,18 @@ kubectl annotate secret my-secret -n parent propagate.hnc.x-k8s.io/select=child1
382392
kubectl annotate secret my-secret -n parent propagate.hnc.x-k8s.io/select='!child2.tree.hnc.x-k8s.io/depth, !child3.tree.hnc.x-k8s.io/depth'
383393
```
384394

385-
To set `my-secret` not to propagate to any namespace, you can use:
395+
To set `my-secret` not to propagate to any namespace when the sync mode is `Propagate`, you can use:
386396

387397
```bash
388398
kubectl annotate secret my-secret -n parent propagate.hnc.x-k8s.io/none=true
389399
```
390400

401+
To set `my-secret` to propagate to any namespace when the sync mode is `AllowPropagate`, you can use:
402+
403+
```bash
404+
kubectl annotate secret my-secret -n parent propagate.hnc.x-k8s.io/all=true
405+
```
406+
391407
All these are equivalent to creating the object with the selector annotations:
392408

393409
```bash
@@ -677,6 +693,10 @@ The most important type of configuration is the way each object type
677693

678694
* **Propagate:** propagates objects from ancestors to descendants and deletes
679695
obsolete descendants.
696+
* **AllowPropagate:** opt-in propagation - only propagates objects from ancestors
697+
to descendants and deletes obsolete descendants when at least one
698+
[selector](#limit-the-propagation-of-an-object-to-descendant-namespaces) is set
699+
on the object.
680700
* **Remove:** deletes all existing propagated copies, but does not touch source
681701
objects.
682702
* **Ignore:** stops modifying this resource. New or changed objects will not be
@@ -700,7 +720,7 @@ To configure an object resource using the kubectl plugin:
700720

701721
```
702722
# "--group" can be omitted if the resource is a core K8s resource
703-
kubectl hns config set-resource [resource] --group [group] --mode [Propagate|Remove|Ignore]
723+
kubectl-hns config set-resource RESOURCE [--group GROUP] [--force] --mode <Propagate|Remove|Ignore|AllowPropagate>
704724
```
705725

706726
For example:
@@ -737,20 +757,20 @@ spec:
737757
mode: Propagate <<<
738758
```
739759
740-
Adding a new resource in the `Propagate` mode is potentially dangerous, since
741-
there could be existing objects of that resource type that would be overwritten
742-
by objects of the same name from ancestor namespaces. As a result, the HNS
743-
plugin will not allow you to add a new resource directly in the `Propagate`
744-
mode. Instead, to do so safely:
760+
Adding a new resource in the `Propagate` mode or `AllowPropagate` mode is potentially
761+
dangerous, since there could be existing objects of that resource type that
762+
would be overwritten by objects of the same name from ancestor namespaces.
763+
As a result, the HNS plugin will not allow you to add a new resource directly
764+
in the `Propagate` mode or `AllowPropagate`. Instead, to do so safely:
745765

746766
* Add the new resource in the `Remove` mode. This will remove any propagated
747767
copies (of which there should be none) but will force HNC to start
748768
synchronizing all known source objects.
749769
* Wait until `kubectl hns config describe` looks like it's identified the
750770
correct number of objects of the newly added resource in its status.
751-
* Change the propagation mode from `Remove` to `Propagate`. HNC will then check
752-
to see if any objects will be overwritten, and will not allow you to change
753-
the propagation mode until all such conflicts are resolved.
771+
* Change the propagation mode from `Remove` to `Propagate` or `AllowPropagate`.
772+
HNC will then check to see if any objects will be overwritten, and will not
773+
allow you to change the propagation mode until all such conflicts are resolved.
754774

755775
Alternatively, if you're certain you want to start propagating objects
756776
immediately, you can use the `--force` flag with `kubectl hns config

0 commit comments

Comments
 (0)