docs(MADR): policy on namespace

[lobkovilya]

Checklist prior to review

• Link to relevant issue as well as docs and UI issues -- Fix MADR for applying new policies on different namespaces #7269
• This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as a image registry) and it will work on Windows, system specific functions like syscall.Mkfifo have equivalent implementation on the other OS --
• Tests (Unit test, E2E tests, manual test on universal and k8s) --
  • Don't forget ci/ labels to run additional/fewer tests
• Do you need to update UPGRADE.md? --
• Does it need to be backported according to the backporting policy? (this GH action will add "backport" label based on these file globs, if you want to prevent it from adding the "backport" label use no-backport-autolabel label) --

[lahabana]

This MADR is very hard to follow for the following reasons:

1. It should probably start by introducing Consumer and Producer policies which I think are paramount to understand what this is about.
2. It starts by explaining the implementation which is confusing as you haven't explained what you want to do.

[lahabana]

The 2 sentences contradict each other.

[lobkovilya]

Why? The first sentence says policy in the custom namespaces affects requests to the custom namespace (not pods in the custom namespace). And the second sentence just elaborates – since some policies are applied on the client-side the policy scope is no longer limited to policy's namespace.

[lahabana]

I think I didn't see requests. I had to reread this 3 times, I think it could be made more clear

[lahabana]

I think this: #10247 suggests an alternative more straightforward approach in this case that may simplify a lot of things

[lahabana]

While thinking about: #10247 and thinking about syncing to zones with producer/consumer policies it struck me that you could have multiple to entries with different kinds (one could be producer, the other consumer). What would be the syncing behaviour in this case?

[lobkovilya]

While thinking about: #10247 and thinking about syncing to zones with producer/consumer policies it struck me that you could have multiple to entries with different kinds (one could be producer, the other consumer). What would be the syncing behaviour in this case?

The new validation rules are going to limit what policies you can create. If top-level targetRef doesn't specify kuma.io/zone and k8s.kuma.io/namespace then each item in to[] has to specify both kuma.io/zone and k8s.kuma.io/namespace. That's kind of a downside we're having with new design – consumer policies must have kuma.io/zone and k8s.kuma.io/namespace tags in top-level targetRef, i.e Frontend Owner wants to change how frontend communicates with others:

metadata:
  namespace: frontend-ns
  labels:
    kuma.io/origin: zone
spec:
  targetRef:
    kind: MeshSubset
    tags:
      kuma.io/zone: i-have-to-know-the-name-of-my-zone
      k8s.kuma.io/namespace: frontend-ns
  to:
    - targetRef:
        kind: Mesh
      default: {}

[lahabana]

This will be enforced by validation webhook

[lahabana]

This is the first ocurence of the work "producer" so it's not "mentioned previously"

[lahabana]

Hmm why? I'm confused I think I need an example to understand this

[lobkovilya]

The next section #### Enhanced validation provides more details and also has some examples.

[lahabana]

I don't think that's necessary you can always use a top spec.tagerRef.kind: MeshSubset to reduce blast radius no? That's what it is for no?

[lobkovilya]

It probably wasn't clear that these points:

* Enhanced validation...
* Ability to opt-in or opt-out...

are followed by the separate sections to elaborate on each point:

#### Enhanced validation
...
#### Considered options on opting-in(out) to cross-zone policy syncing
...

and the decision for opting-in(out) is exactly what you said – we can always use a top spec.targetRef.kind: MeshSubset to reduce blast radius.

[lahabana]

That seems unnecessarily annoying. Again UX is important here!

[lahabana]

Isn't from policy on custom namespace having an "implicit MeshSubset" a better behaviour? Especially if we go for #10247 top level targetRef slowly disappears.

[lahabana]

Also with the current zone originated policies is similar to having an implicit MeshSubset no?

[lahabana]

Annoying!

[lahabana]

Not only undesired? Let's say 1 zone is very far away maybe the operator will add increased default timeouts.

[lahabana]

Can we just write pseudo code? This is hard to process

[lahabana]

targeting where? to? top level?

[lahabana]

This namespace can be implicit right?
Also, if this namespace were different from frontend-ns would this be rejected?

[lahabana]

This is equivalent to having the implicit namespace: frontend-ns ?
What would happen if I had namespace: backend-ns

Finally what happens with:

type: MeshCircuitBreaker
mesh: default
name: circuit-breaker
namespace: frontend-ns
spec:
  targetRef:
    kind: MeshGateway
    name: edge-gateway
  to:
  - targetRef:
      kind: MeshService # you need to specify MeshService in to[].targetRef.kind
      name: frontend
     default: {}
  - targetRef:
      kind: MeshService
      name: backend
      namespace: backend-ns
    default: {}

My gut feeling is that this should rejected (entries in the to must have the same namespace). We should likely suggest users to not set multiple to entries

[Icarus9913]

I just get confused with the example, it looks like a cross namespace control?
So, can we define our top TargetRef MeshSubset with another NS front-end if our policy is backend-ns?

Actually, I feel it's pretty complicated in the cross-namespace use cases definition :(

[Icarus9913]

OK, I just get understand with this.
Maybe we should also paste the link here: https://gateway-api.sigs.k8s.io/mesh/#gateway-api-for-service-mesh

For those people who are unfamiliar with the context