Skip to content
This repository has been archived by the owner on Sep 14, 2020. It is now read-only.

Auto-guessing the peering mode #33

Closed
3 of 4 tasks
nolar opened this issue Apr 21, 2019 · 2 comments
Closed
3 of 4 tasks

Auto-guessing the peering mode #33

nolar opened this issue Apr 21, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@nolar
Copy link
Contributor

nolar commented Apr 21, 2019

Current Behaviour

Currently, the peering object is needed by default, unless --standalone option is used, which disables the peering completely.

This causes the confusion for the first intro and following the tutorial — in case the cluster is not configured yet (no peering objects created). See: #31.

If standalone mode is made the default, there is a negative side-effect: if somebody runs 2+ operators —e.g. one in-cluster, another in the dev-mode on the external workstations— these operators will collide and compete for the objects without knowing this. The peering was invented exactly for the purpose of not hitting this issue in the dev-mode, and gracefully "suppressing" other operators.

Expected Behaviour

The peering should be considered as a side-feature for extra safety, it should not be a showstopper for the quick-start guides or tutorials.

It would be better to have 3 modes:

  • with --peering or --peering=something, the peering is enforced, the operator fails to start if peering is not accessible (as it is now).
  • with --standalone, the peering is ignored (as it is now).
  • with no options (the new default), the auto-detection mode is used: if the "metadata.name: default" peering object is found, use it (either cluster-scoped or namespace-scoped, depending on --namespace=); if not found, log a big-letter warning of possible conflicts and collisions, and continue as if in the standalone mode.

Relevant: #32.

Todos:

  • Documentation:
    • CLI options.
    • Peering page.
  • Tests.
@s-soroosh
Copy link
Contributor

@nolar I think it's better to not support --peering as flag. It might bring ambiguity in cases like this:
run ../examples/01-minimal/example.py --peering --verbose
It can be interpreted as a peering with name --verbose.
IMO it's safe to switch to auto-mode if --peering does not exist and just show the warning to the user.
wdyt?

s-soroosh added a commit to s-soroosh/kopf that referenced this issue Apr 22, 2019
s-soroosh added a commit to s-soroosh/kopf that referenced this issue Apr 22, 2019
s-soroosh added a commit to s-soroosh/kopf that referenced this issue Apr 22, 2019
Co-Authored-By: psycho-ir <soroosh.sarabadani@gmail.com>
@nolar
Copy link
Contributor Author

nolar commented Apr 22, 2019

I think it's better to not support --peering as flag.

@psycho-ir Agree. Also, it is unclear what is meant if it is just a flag: which peering object to use.

I've fixed the issue text.

s-soroosh added a commit to s-soroosh/kopf that referenced this issue Apr 23, 2019
nolar added a commit that referenced this issue Apr 24, 2019
[GH-33] implement auto detection mode for peering.
@nolar nolar closed this as completed Apr 25, 2019
@nolar nolar added this to the 1.0 milestone Apr 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants