Improve Hyper-V performance by reduce duplicate Hyper-V operations

[lingsamuel]

See #10135

docker-env and status need 10s in average. Seems like each Hyper-V operation (get running state, get ip addr) takes 2s+.

Comparison: Linux OS < 1s

/kind feature

[lingsamuel]

/label os/windows

[k8s-ci-robot]

@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

In response to this:

/label os/windows

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[medyagh]

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

[lingsamuel]

From the log I pasted #10135 we can say it repeat .state at least 3 times and get ip address twice

[lingsamuel]

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())
• New a CommandRunner (SSH here) has a State and IP access (inside GetSSHHostname())

[lingsamuel]

Some libmachine codes: GetIP, GetState, GetSSHHostname()

From the code we know machine-drivers/machine doesn't cache anything.

[lingsamuel]

The strange thing is the lib already set IP inside Start().
Is there any reason to retrieve IP every time?

[lingsamuel]

By this simple patch, docker-env and status only need 2s currently (1 State call).

[lingsamuel]

xref machine-drivers/machine#31

[lingsamuel]

Can we use a fork version with this patch machine-drivers/machine#32? @medyagh

[fejta-bot]

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

[fejta-bot]

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

[lingsamuel]

/remove-lifecycle rotten

[lingsamuel]

Any updates? I think I've provided enough information to confirm this.
/ping @medyagh

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[sharifelgamal]

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.