Azure CNI creates lots of short lived calls to WMI

[jsturtevant]

What happened:
Azure CNI creates lots of short lived calls to WMI.

1. Wmic.exe processes were launched by azure-vnet.exe in session 0 to query system bootup time.
2. azure-vnet.exe is short lived process and the calls to WMI are expensive

what is the purpose and is there away to optimize these calls?

What you expected to happen:

How to reproduce it:

Orchestrator and Version (e.g. Kubernetes, Docker):

Operating System (Linux/Windows):

Kernel (e.g. uanme -a for Linux or $(Get-ItemProperty -Path "C:\windows\system32\hal.dll").VersionInfo.FileVersion for Windows):

Anything else we need to know?:
[Miscellaneous information that will assist in solving the issue.]

[rbtr]

afaik we use the reboot time to determine if we need to release dangling locks or rebuild our local state, since it will be inconsistent after a node reboot (on linux we store these on the tmpfs so they're automatically flushed during a reboot). @tamilmani1989 should be able to provide more context or discuss optimization.

[zhiweiv]

Is #529 a solution for this?

[jsturtevant]

looks like it could be, the 500ms vs ~0ms is good example of the cost. Was there a reason it was closed with out merging?

[tamilmani1989]

@jsturtevant thanks for raising this. we removed logic of cleaning up state/lock based on reboot time recently. Still cni gets reboot time(using wmic) just for logging/debugging purpose. we can certainly evaluate this PR #529 and merge if necessary

@zhiweiv can you please reopen the PR?

[zhiweiv]

I opened a new PR #966, please take a look.