You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Commented by psycho-ir at 2019-04-22 10:26:50+00:00
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?
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:
--peering
or--peering=something
, the peering is enforced, the operator fails to start if peering is not accessible (as it is now).--standalone
, the peering is ignored (as it is now).--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:
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?
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.
The text was updated successfully, but these errors were encountered: