Expose more advanced ZooKeeper ServerSets configuration #1516
Comments
|
We should probably just replace the default inet resolver throughout linkerd. i don't think that's ever good behavior for linkerd? |
|
@b-hoyt we're going to discuss / scope this today |
|
@olix0r I haven't been able to brainstorm a scenario when it is good behavior yet. Making the single surgical change (default inet resolver = not fixed) would solve my immediate problem, extra configurability would be a bonus, although it could also be too much rope. |
adleong
added this to Medium-Term
in Linkerd 1.x Backlog. See https://github.com/linkerd/linkerd2/blob/main/ROADMAP.md
|
@b-hoyt This is doable but not 100% trivial. Current plan it to take a look at this in a bit; for the next release, at least, we'd like to focus on H2 features and perf. |
olix0r
moved this from Medium-Term
to Short-Term
in Linkerd 1.x Backlog. See https://github.com/linkerd/linkerd2/blob/main/ROADMAP.md
Tim-Brooks
pushed a commit
to Tim-Brooks/linkerd
that referenced
this issue
Dec 20, 2018
If an input file is un-injectable, existing inject behavior is to simply output a copy of the input. Introduce a report, printed to stderr, that communicates the end state of the inject command. Currently this includes checking for hostNetwork and unsupported resources. Malformed YAML documents will continue to cause no YAML output, and return error code 1. This change also modifies integration tests to handle stdout and stderr separately. example outputs... some pods injected, none with host networking: ``` hostNetwork: pods do not use host networking...............................[ok] supported: at least one resource injected..................................[ok] Summary: 4 of 8 YAML document(s) injected deploy/emoji deploy/voting deploy/web deploy/vote-bot ``` some pods injected, one host networking: ``` hostNetwork: pods do not use host networking...............................[warn] -- deploy/vote-bot uses "hostNetwork: true" supported: at least one resource injected..................................[ok] Summary: 3 of 8 YAML document(s) injected deploy/emoji deploy/voting deploy/web ``` no pods injected: ``` hostNetwork: pods do not use host networking...............................[warn] -- deploy/emoji, deploy/voting, deploy/web, deploy/vote-bot use "hostNetwork: true" supported: at least one resource injected..................................[warn] -- no supported objects found Summary: 0 of 8 YAML document(s) injected ``` TODO: check for UDP and other init containers Part of linkerd#1516 Signed-off-by: Andrew Seigner <[email protected]>
Tim-Brooks
pushed a commit
to Tim-Brooks/linkerd
that referenced
this issue
Dec 20, 2018
linkerd only routes TCP data, but `linkerd inject` does not warn when it injects into pods with ports set to `protocol: UDP`. Modify `linkerd inject` to warn when injected into a pod with `protocol: UDP`. The Linkerd sidecar will still be injected, but the stderr output will include a warning. Also add stderr checking on all inject unit tests. Part of linkerd#1516. Signed-off-by: Andrew Seigner <[email protected]>
Tim-Brooks
pushed a commit
to Tim-Brooks/linkerd
that referenced
this issue
Dec 20, 2018
`linkerd inject` was not checking its input for known sidecars and initContainers. Modify `linkerd inject` to check for existing sidecars and initContainers, specifically, Linkerd, Istio, and Contour. Part of linkerd#1516 Signed-off-by: Andrew Seigner <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be helpful for some of the more advanced configuration for ZooKeeper ServerSets to be exposed in YAML so defaults can be overridden if desired.
Specifically:
removalWindow
batchWindow
unhealthyWindow
inetResolver
The default InetResolver is FixedInetResolver which hangs on unresolvable hostnames: https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/InetResolver.scala#L214
If a zookeeper server set has even one unresolvable hostname in it, the FixedInetResolver spin prevents any of the hostnames in the set from returning.
Being able to swap in the ordinary InetResolver (non-fixed) addresses this problem, effectively filtering unresolvable hostnames until they later resolve, but allowing resolvable hostnames through.
The text was updated successfully, but these errors were encountered: