Use GetVersion() API instead of ver command

[feiskyer]

What this PR does / why we need it:

Should use GetVersion vs Shelling out to ver.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #55083

Special notes for your reviewer:

Release note:

NONE

[feiskyer]

Note that with this PR the kernel verson is in different format as before, e.g. on my local windows 10 laptop

• ver command would output 10.0.16299.19
• while GetVersion would got 16299.15.amd64fre.rs3_release.170928-1534

/cc @taylorb-microsoft is this what we expected?

[thecloudtaylor]

@feiskyer - thanks for coding this up so quickly!

• For windows versions the kernel matches usermode so there is only one version.
• Explanation of fields from ver:
  • The first two fields (10.0) specific the OS Major version, which is unlikely to change but you can get it from GetVersionEX (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724833(v=vs.85).aspx)
  • The third field (16299) is the buildNumber - that number is important as it increments with every full build.
  • The fourth field (19) is the UBR number, which is really what is required from the registry. The UBR number specifies what updates have been applied, each new Windows update increments this number.
• Expiation of fields from BuildLabEx
  • First field is the (16299) is the buildNumber (you can also query the CurrentBuildNumber key vs parsing)
  • Second field is the UBR number ( you can also query the UBR key vs parsing)
  • Third field is the architecture
  • Forth field is the build Branch ( you can also query the BuildBranch key vs parsing)
  • Fifth field is the time stamp (not overly helpful unless your part of the Windows team)

[thecloudtaylor]

Ideally should update comment to proper binary name.

[thecloudtaylor]

To your question on why ver is returning a different URB than what is in the BuildLabEx registry key I'm not sure - can you see what its in that key vs the UBR key? The ver code queries the UBR key for that information.

Specifically what they are doing is:

1. Call GetVersion() (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724439(v=vs.85).aspx)
2. Call an local GetVersionRevision() API - which uses the UBR registry key
3. Format a string:
   "%d.%d.%05d.%d", (ver & 0xFF), ((ver >> 8) & 0xFF), ((ver >> 16) & 0xFFFF), revision)

[feiskyer]

@taylorb-microsoft Addressed comments. PTAL

[feiskyer]

/retest

[feiskyer]

/retest

[feiskyer]

/assign @yujuhong @tallclair

[JiangtianLi]

@feiskyer @taylorb-microsoft Thanks for fixing this. I have a similar fix in #55496 but will revert to use yours. One question, for Linux,

OS-IMAGE                              KERNEL-VERSION
Debian GNU/Linux 8 (jessie)           4.11.0-1013-azure

Should the osImageVersion be something more verbal such as "Microsoft Windows 10 Enterprise" or "Microsoft Windows Server Datacenter", e.g. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName? Just my 2 cents.

[feiskyer]

@tallclair Addressed comments. PTAL

[feiskyer]

/retest

[tallclair]

/lgtm

[k8s-github-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: feiskyer, tallclair

Associated issue: 55083

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

• pkg/kubelet/OWNERS [tallclair]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

[feiskyer]

@tallclair Thanks. Could you also help to approve the milestone?

[k8s-github-robot]

[MILESTONENOTIFIER] Milestone Pull Request Needs Attention

@feiskyer @tallclair @yujuhong @kubernetes/sig-node-misc

Action required: During code slush, pull requests in the milestone should be in progress.
If this pull request is not being actively worked on, please remove it from the milestone.
If it is being worked on, please add the status/in-progress label so it can be tracked with other in-flight pull requests.

Note: If this pull request is not resolved or labeled as priority/critical-urgent by Wed, Nov 22 it will be moved out of the v1.9 milestone.

Pull Request Labels

• sig/node: Pull Request will be escalated to these SIGs if needed.
• priority/important-soon: Escalate to the pull request owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.
• kind/cleanup: Adding tests, refactoring, fixing old bugs.

Help

• Additional instructions
• Commands for setting labels

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 56115, 55143, 56179). If you want to cherry-pick this change to another branch, please follow the instructions here.