Open lingsamuel opened 3 years ago
/label os/windows
@lingsamuel: The label(s) /label os/windows
cannot be applied. These labels are supported: api-review, community/discussion, community/maintenance, community/question, cuj/build-train-deploy, cuj/multi-user, platform/aws, platform/azure, platform/gcp, platform/minikube, platform/other, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash
thats a good idea @lingsamuel if indeed we doing those operations multiple times. could we verify how many times we actually call those funcs ? maybe adding some debug.Printstack() and them and see how many times we call it and reduce those calls
From the log I pasted #10135 we can say it repeat .state
at least 3 times and get ip address twice
The latency only happens when we are accessing host.Driver.XXX. I suspect the reason is powershell starts slowly.
host, _ := api.Load(machineName)
s, _ := host.Driver.GetState()
Slow operation is Driver.GetState()
.
In status
command:
func nodeStatus(api libmachine.API, cc config.ClusterConfig, n config.Node) (*Status, error) {
// ...
hs, err := machine.Status(api, name)
// ...
if _, err := cluster.DriverIP(api, name); err != nil {
// .....
host, err := machine.LoadHost(api, name)
cr, err := machine.CommandRunner(host)
//...
machine.Status
, has 1 .GetState()
cluster.DriverIP()
has 1 .GetIP()
(from log I found before IP access, there is a State
access, it happened inside GetIP()
)CommandRunner
(SSH here) has a State
and IP
access (inside GetSSHHostname()
)Some libmachine codes: GetIP, GetState, GetSSHHostname()
From the code we know machine-drivers/machine doesn't cache anything.
The strange thing is the lib already set IP inside Start()
.
Is there any reason to retrieve IP every time?
By this simple patch, docker-env
and status
only need 2s currently (1 State
call).
xref machine-drivers/machine#31
Can we use a fork version with this patch https://github.com/machine-drivers/machine/pull/32? @medyagh
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten
/remove-lifecycle rotten
Any updates? I think I've provided enough information to confirm this. /ping @medyagh
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
I believe @afbjorklund has write access to machine-drivers/machine, hopefully he can merge your PR there and we can update the reference in our code here.
See #10135
docker-env
andstatus
need 10s in average. Seems like each Hyper-V operation (get running state, get ip addr) takes 2s+.Comparison: Linux OS < 1s
/kind feature