-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Defer API version negotiation #1747
Defer API version negotiation #1747
Conversation
Can you |
cmd/docker/docker.go
Outdated
|
||
func isNoRemote(cmd *cobra.Command) bool { | ||
for cmd != nil { | ||
if _, ok := cmd.Annotations["no-remote"]; ok { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit, but I don't like negations in names, because you can end up with a double negations, like if !isNoRemote(...)
... and double negations are generally brain fucked 😅
That said, I don't have better name to propose... I thought about "local" but I think it is too vague.
@thaJeztah any idea? 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IsLocal
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IsDaemonLess ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you rename the annotation too? no-remote
-> local-only
?
e87de89
to
427e193
Compare
Codecov Report
@@ Coverage Diff @@
## master #1747 +/- ##
==========================================
+ Coverage 56.26% 56.44% +0.18%
==========================================
Files 308 308
Lines 21293 21354 +61
==========================================
+ Hits 11980 12053 +73
- Misses 8439 8442 +3
+ Partials 874 859 -15 |
427e193
to
dd6d954
Compare
Rebased, rewrote commit text, small refactoring to support checks for both local-only and experimental CLI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, but I fear some regressions as it is like a huge refactoring, and we already saw many regressions on this part before + there are not much tests 😞
Do you think you could add some?
Added a LOT of tests. PTAL @silvin-lubecki, @thaJeztah |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left some comments inline, but looks good overall
ping @simonferquel 🤗 |
403b94d
to
90b2d14
Compare
@thaJeztah @silvin-lubecki I just rebased, extracted the fixes in different PRs (which I am based onto). To fix the problem, I added a notion of "LazyFlagCheck" which allows to add custom validation logic on a flag, which will get executed after the cli is actually initialized. It is a bit ugly around the edges though, and I'd be glad if we could have a different approach. |
90b2d14
to
19c0830
Compare
This commit defers API version negotiation within the dockerCli structure to the point where we need to access server info or the API client itself. This also introduce a "no-remote" annotation, to skip the evaluation of server-side support for those commands (which requires access to server-info). The context subcommands are marked with this "no-remote" annotation so that they respond quickly even if the current context points to an unreachable endpoint. Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
19c0830
to
4975ead
Compare
@thaJeztah PTAL :) (and @silvin-lubecki as well) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve this PR, even if I find this lazycheck logic too complicated. I think it was introduced due to this PR, we should try to fix/simplify that in a follow-up.
Otherwise thank you @simonferquel for the bunch of tests 😍
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
b1537da
to
d35f48c
Compare
Hm.. not sure if it's introduced in this PR, but trying this;
Instead of
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some nits, but I agree with @silvin-lubecki that this adds a lot of complexity; I want to give this another look and see if we can somehow make this less complex. (e.g. just add a local-only
and/or lazy-evaluate
annotation where needed, and skip those if serverinfo
is not present? I'd have to give that some thought.
} | ||
|
||
// EvaluateFlagLazyChacks evaluates the lazy checks associated with a flag depending on client/server info | ||
func EvaluateFlagLazyChacks(flag *pflag.Flag, clientInfo command.ClientInfo, serverInfo command.ServerInfo, clientVersion string) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
func EvaluateFlagLazyChacks(flag *pflag.Flag, clientInfo command.ClientInfo, serverInfo command.ServerInfo, clientVersion string) error { | |
func EvaluateFlagLazyChecks(flag *pflag.Flag, clientInfo command.ClientInfo, serverInfo command.ServerInfo, clientVersion string) error { |
f.Annotations[lazyCheckAnnotation] = append(f.Annotations[lazyCheckAnnotation], fmt.Sprintf("%d", index)) | ||
} | ||
|
||
// EvaluateFlagLazyChacks evaluates the lazy checks associated with a flag depending on client/server info |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// EvaluateFlagLazyChacks evaluates the lazy checks associated with a flag depending on client/server info | |
// EvaluateFlagLazyChecks evaluates the lazy checks associated with a flag depending on client/server info |
@@ -8,6 +8,8 @@ import ( | |||
"strings" | |||
"syscall" | |||
|
|||
"github.com/docker/cli/cli/command/commands/lazychecks" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be grouped with the imports below
@thaJeztah bad news, it does the same thing on master. Toplevel flags seem to be set twice for some reason. For flags of type "list" it insert the same value twice. |
This partially mitigates docker#1739 ("Docker commands take 1 minute to timeout if context endpoint is unreachable") and is a simpler alternative to docker#1747 (which completely defers the client connection until an actual call is attempted). Note that the previous 60s delay was the culmination of two separate 30s timeouts since the ping is tried twice. This with this patch the overall timeout is 20s. moby/moby#39206 will remove the second ping and once that propagates to this tree the timeout will be 10s. Signed-off-by: Ian Campbell <ijc@docker.com>
@thaJeztah hi, digging a bit in history, any reason for holding this one ? It looks like something that might be needed for #2420. |
I'd have to look into this one again; I know I wasn't particularly happy with the amount of complexity involved. Wondering if using the |
I see this PR is on master, but not in the 19.03 release; #1845. Haven't tested if it solves the delay though |
- What I did
Fix #1739 by deferring the API version negotiation to the point we actually need access to either the
ServerInfo
or the API client interface.Also introduce a
no-remote
annotation for marking commands that do not require anything on the daemon side to work. Commands annotated as such are not evaluated by the conditional hiding feature (which relies on ServerInfo to get access to the daemon OS, experimental flag, etc.).Context commands are annotated as no-remote
- How to verify it
docker context create faulty --docker host=tcp://42.42.42.41:4242
docker context use faulty
docker info
)docker context ls
)CC @silvin-lubecki @thaJeztah