Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PR] Peering scopes #36

Closed
3 tasks done
kopf-archiver bot opened this issue Aug 18, 2020 · 0 comments
Closed
3 tasks done

[PR] Peering scopes #36

kopf-archiver bot opened this issue Aug 18, 2020 · 0 comments
Labels
archive enhancement New feature or request

Comments

@kopf-archiver
Copy link

kopf-archiver bot commented Aug 18, 2020

A pull request by nolar at 2019-04-22 01:51:13+00:00
Original URL: zalando-incubator/kopf#36
Merged by nolar at 2019-05-17 11:22:59+00:00

Issue : #32, related #31, #17

For the purpose of strict namespace isolation of the operators, the peering objects must be cluster- or namespace-scoped (previously: always cluster-scoped).

For this, split the old cluster-wide KopfPeering resource into the new ClusterKopfPeering & namespaced KopfPeering, and use one of them depending on the --namespace option.

The testing of peering is performed manually — it works. More tests will be added when the whole peering subsystem will be covered with tests (as part of #13).

Docs preview:

See also: #37 for the namespace isolation of the listing/watching API calls.

TODO:

  • Manually test how do the operators react to changes in the kind: KopfPeering when re-created from the cluster to the namespaced scope — in different running modes (with/without --peering, with/without --namespace). Ensure that the operators actually behave as before and as expected.
  • Fallback to the old CRD KopfPeering if that CRD is cluster-scoped (but not if namespaced).
  • Document the upgrade scenario to code first, CRDs second, never vice versa.

Commented by nolar at 2019-05-15 15:30:50+00:00
 

So far, as tested with Minikube, the behaviour is this:

  • Baseline: Old code, old peerings (KopfPeering is cluster-scoped, ClusterKopfPeering does not exist):
    • No CLI options: Auto-detection mode, cluster-wide peering was used.
    • --namespace=default: Uses the cluster-wide peering.
    • --peering=default: Uses the cluster-wide peering.
    • --namespace=default --peering=default: Uses the cluster-wide peering.
  • Mainline: New code, old peerings (KopfPeering is cluster-scoped, ClusterKopfPeering does not exist):
    • No CLI options: Auto-switches to standalone mode with a warning (mismatches❗️).
    • --namespace=default: Uses the cluster-wide peering (as expected ✅ ).
    • --peering=default: Fails with "The peering was not found (mismatches❗️).
    • --namespace=default --peering=default: Uses the cluster-wide peering (as expected ✅ ).
  • Edgecase: Old code, new peerings (KopfPeering is namespaced, ClusterKopfPeering is cluster-scoped).
    • Fails with "Namespace parameter required" (mismatches❗️).

Both cases of (new code + old peerings) fail because they try to use the ClusterKopfPeering CRD, which does not exist there — due to if namespace is None condition. They work fine if the CRD is the old one, KopfPeering.


All cases of (old code + new peerings) fail since they use the now-namespaced CRD (KopfPeering) with a cluster-scoped method (get_cluster_custom_object()).

This is not solvable, since it can only be done with a new version which supports the fallback to ClusterKopfPeering — and if one needs to upgrade, why not to upgrade to the new code with both old & new peerings supported; i.e. the transitional releases make no sense.


Commented by nolar at 2019-05-15 16:21:04+00:00
 

Rebased on master, and added the fallback scenario for the legacy mode (cluster-scoped KopfPeering). As tested manually, the new code works as expected both in the legacy mode (of the cluster) and in the new mode (as documented).

samurang87 aweller It can be reviewed and merged to master now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
archive enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

0 participants