Fix description for same/notSameLabels; remove NamespaceRelation

[tssurya]

Closes #45 (comment). See #45 (comment) for details.

This PR is removing Related field. TODO: Add docs to show how this can be achieved using same/notSame Labels.

In addition to that we are trying to clarify the meaning of same/notSame labels.

[netlify]

✅ Deploy Preview for kubernetes-sigs-network-policy-api ready!

Name	Link
🔨 Latest commit	2a9aa3d
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-network-policy-api/deploys/6458d786b03cfe0008dab4a8
😎 Deploy Preview	https://deploy-preview-75--kubernetes-sigs-network-policy-api.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[tssurya]

woops need to fix the verify

[npinaeva]

Maybe we can follow the notin LabelSelector notation like https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement, so that a namespace is selected when for every listed label, if that namespace has this label with a different value, or the label is not set?
Edit: one thing we need to figure out is if these labels should be ANDed or OR'd

[danwinship]

You should look at the user stories to see what functionality is needed, but I think the intention was that notSameLabels: ["x", "y", "z"] matches exactly the set of namespaces that sameLabels: ["x", "y", "z"] doesn't match. [EDIT: which I think matches what Nadia said?]

Related: sameLabels: ["x"] is not well-defined if the subject namespace doesn't have the label "x". (The current text would require the matched namespace to have the label "x" with the same value as the subject namespace, but the subject namespace has no value for it (not even "").)

[Dyanngg]

Related: sameLabels: ["x"] is not well-defined if the subject namespace doesn't have the label "x". (The current text would require the matched namespace to have the label "x" with the same value as the subject namespace, but the subject namespace has no value for it (not even "").)

In that case I think the peer will always evaluate to an empty one, because if the subject's Namespace does not even have the label "x", we have no ground for deducing what Namespaces have the same labels at all

[npinaeva]

I think in case subject doesn't have a label set, I would logically expect sameLabels to be all namespace with the same label unset. But it probably doesn't make sense in the ANP context, so what @Dyanngg said is reasonable, we can just ignore subjects with unset labels.
On the other side, this behaviour is not obvious, but we can add a doc recommendation to always put LabelSelector[MatchExpressions: [labelName, Exists]] in the subject for every label that is used in the same/notSameLabels peers (or make another object with subject based on the same labels :) )

Another tricky part is how to define multiple labels. I guess we understand same labels like sameLabels: [L1, ..., Ln] = sameLabels: [L1] && ... && sameLabels: [Ln]
If we want notSameLabels to be a complement to sameLabels, then
notSameLabels: [L1, ..., Ln] = not(sameLabels: [L1, ..., Ln]) = not (sameLabels: [L1] && ... && sameLabels: [Ln]) = not sameLabels: [L1] || ... || not sameLabels: [Ln], so if at least one label is different, it will be matched.
On the other hand, I can define the same logical OR with multiple 1-label peers, but I don't have a way to define not sameLabels: [L1] && not sameLabels: [L2] to only match when both labels are different. It's ok if we don't have a use case for that, but I think we still need to consider this limitation.

[tssurya]

the matched namespace to have the label "x" with the same value as the subject namespace, but the subject namespace has no value for it (not even "").)

+1 no peers will match that.

[tssurya]

Maybe we can follow the notin LabelSelector notation like https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement, so that a namespace is selected when for every listed label, if that namespace has this label with a different value,

yes this is what I am going with similar to what @Dyanngg said

or the label is not set?

This is debatable on which way to go... by label not being set you mean a nil value right? but the key must exist, we don't want to assume a match on things that don't have keys set - notIn also seems to match on different values of the same key.

[astoycos]

In that case I think the peer will always evaluate to an empty one, because if the subject's Namespace does not even have the label "x", we have no ground for deducing what Namespaces have the same labels at all

I agree with Yang here

I think the intention was that notSameLabels: ["x", "y", "z"] matches exactly the set of namespaces that sameLabels: ["x", "y", "z"] doesn't match. [EDIT: which I think matches what Nadia said?]

So yeah the use cases are vague here, essentially we just want to make designing tenants simple.... however I think it makes most sense to ensure that notSameLabels is the exact inverse of sameLabels. i.e

	// To be selected a Namespace must have all of the labels defined in NotSameLabels,
	// AND at least one of them must have different values than the subject of this policy.
	// If NotSameLabels is empty then nothing is selected.

Should be

	// To be selected a Namespace must have all of the labels defined in NotSameLabels,
	// AND all of them must have different values than the subject of this policy.
	// If NotSameLabels is empty then nothing is selected.

[astoycos]

Ping @tssurya WDYT about @Dyanngg's comments? I'd like to get this in before actually doing a release payload for V1alpha1 :)

[astoycos]

Blocking #90

[tssurya]

@astoycos : Yes let me update this with the suggestions, (was on PTO the last week for a few days saw the ping only now)

[tssurya]

@astoycos @Dyanngg: PTAL

[astoycos]

/lgtm
/approve

Thanks @tssurya

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: astoycos, tssurya

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [astoycos]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment