OCPBUGS-6635: [build] Fix k8s version reporting

[aravindhp]

The openshift/kubernetes repo does not propagate all tags from upstream. Only the X.Y.0 tag is propagated. This causes the Windows kubelet and kube-proxy Z version to lag behind its Linux counterparts. The Linux build of kubelet and kube-proxy figures out the Z version at build time. To do something similar for Windows, we can leverage the hack/update_submodules.sh script which is always used to update the kubelet and kube-proxy submodules. To achieve this, the following changes are made:

• Add kubelet and kube-proxy version variables to the Makefile along with make endpoints
• Call these make endpoints in the Dockerfile
• Update hack/update_submodules.sh to pull upstream tags and generate a commit that updates the Makefile version variables

Now the built binaries will have the correct version encoded in them.

Example version update commit:

commit 8f94380e384218561c8b9c3b4158cf2679d17fce (master-submodule-update-02-08)
Author: Aravindh Puthiyaparambil <redacted>
Date:   Wed Feb 8 09:12:47 2023 -0800

    [build] Update kube-proxy version to v1.25.1+72939b9
    
    This commit was generated using hack/update_submodules.sh

diff --git a/Makefile b/Makefile
index 3cbb0c07..43b55d8a 100644
--- a/Makefile
+++ b/Makefile
@@ -8,7 +8,7 @@ WMCO_VERSION ?= 8.0.0
 # *_GIT_VERSION are the k8s versions. Any update to the build line could potentially require an update to the sed
 # command in generate_k8s_version_commit() in hack/update_submodules.sh
 KUBELET_GIT_VERSION=v1.26.0+feedbee
-KUBE-PROXY_GIT_VERSION=v1.26.0+feedbee
+KUBE-PROXY_GIT_VERSION=v1.25.1+72939b9
 
 # CHANNELS define the bundle channels used in the bundle.
 # Add a new line here if you would like to change its default config. (E.g CHANNELS = "preview,fast,stable")

[openshift-ci-robot]

@aravindhp: This pull request references Jira Issue OCPBUGS-6635, which is invalid:

• expected the bug to target the "4.13.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

The openshift/kubernetes repo does propagate all tags from upstream. Only the X.Y.0 tag is propagated. This cause the Windows kubelet and kube-proxy Z version to lag behind its Linux counterparts. The Linux build of kubelet and kube-proxy figures out the Z version at build time. To do something similar for Windows, we can leverage the hack/update_submodules.sh script which is always used to update the kubelet and kube-proxy submodules. To achieve this, the following changes are made:

• Add kubelet and kube-proxy version variables to the Makefile along with make endpoints
• Call these make endpoints in the Dockerfile
• Update hack/update_submodules.sh to pull upstream tags and generate a commit that updates the Makefile version variables

Now the built binaries will have the correct version encoded in them.

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.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[aravindhp]

/approve cancel
/jira refresh

[openshift-ci-robot]

@aravindhp: This pull request references Jira Issue OCPBUGS-6635, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.13.0) matches configured target version for branch (4.13.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @rrasouli

In response to this:

/approve cancel
/jira refresh

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.

[aravindhp]

/test build
/test images
/test platform-none-vsphere-e2e-operator

[aravindhp]

/test build
/test images
/test platform-none-vsphere-e2e-operator

[aravindhp]

From the kube-proxy.log

I0208 00:58:14.705438    3148 server.go:661] "Version info" version="v1.26.0+feedbee"

[aravindhp]

/test gcp-e2e-operator

Not sure why the kubelet.log is empty in the platform-none-vsphere-e2e-operator test

[sebsoto]

@aravindhp WRT the commit message, should

repo does propagate all tags from upstream

read:

repo does *not* propagate all tags from upstream

?

[aravindhp]

@aravindhp WRT the commit message, should

repo does propagate all tags from upstream

read:

repo does *not* propagate all tags from upstream

?

Sorry my bad. You are correct.

[openshift-ci-robot]

@aravindhp: This pull request references Jira Issue OCPBUGS-6635, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.13.0) matches configured target version for branch (4.13.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @rrasouli

In response to this:

The openshift/kubernetes repo does not propagate all tags from upstream. Only the X.Y.0 tag is propagated. This cause the Windows kubelet and kube-proxy Z version to lag behind its Linux counterparts. The Linux build of kubelet and kube-proxy figures out the Z version at build time. To do something similar for Windows, we can leverage the hack/update_submodules.sh script which is always used to update the kubelet and kube-proxy submodules. To achieve this, the following changes are made:

• Add kubelet and kube-proxy version variables to the Makefile along with make endpoints
• Call these make endpoints in the Dockerfile
• Update hack/update_submodules.sh to pull upstream tags and generate a commit that updates the Makefile version variables

Now the built binaries will have the correct version encoded in them.

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.

[openshift-ci-robot]

@aravindhp: This pull request references Jira Issue OCPBUGS-6635, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.13.0) matches configured target version for branch (4.13.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @rrasouli

In response to this:

The openshift/kubernetes repo does not propagate all tags from upstream. Only the X.Y.0 tag is propagated. This causes the Windows kubelet and kube-proxy Z version to lag behind its Linux counterparts. The Linux build of kubelet and kube-proxy figures out the Z version at build time. To do something similar for Windows, we can leverage the hack/update_submodules.sh script which is always used to update the kubelet and kube-proxy submodules. To achieve this, the following changes are made:

• Add kubelet and kube-proxy version variables to the Makefile along with make endpoints
• Call these make endpoints in the Dockerfile
• Update hack/update_submodules.sh to pull upstream tags and generate a commit that updates the Makefile version variables

Now the built binaries will have the correct version encoded in them.

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.

[openshift-ci-robot]

@aravindhp: This pull request references Jira Issue OCPBUGS-6635, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.13.0) matches configured target version for branch (4.13.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @rrasouli

In response to this:

The openshift/kubernetes repo does not propagate all tags from upstream. Only the X.Y.0 tag is propagated. This causes the Windows kubelet and kube-proxy Z version to lag behind its Linux counterparts. The Linux build of kubelet and kube-proxy figures out the Z version at build time. To do something similar for Windows, we can leverage the hack/update_submodules.sh script which is always used to update the kubelet and kube-proxy submodules. To achieve this, the following changes are made:

• Add kubelet and kube-proxy version variables to the Makefile along with make endpoints
• Call these make endpoints in the Dockerfile
• Update hack/update_submodules.sh to pull upstream tags and generate a commit that updates the Makefile version variables

Now the built binaries will have the correct version encoded in them.

Example version update commit:

commit 8f94380e384218561c8b9c3b4158cf2679d17fce (master-submodule-update-02-08)
Author: Aravindh Puthiyaparambil <redacted>
Date:   Wed Feb 8 09:12:47 2023 -0800

   [build] Update kube-proxy version to v1.25.1+72939b9
   
   This commit was generated using hack/update_submodules.sh

diff --git a/Makefile b/Makefile
index 3cbb0c07..43b55d8a 100644
--- a/Makefile
+++ b/Makefile
@@ -8,7 +8,7 @@ WMCO_VERSION ?= 8.0.0
# *_GIT_VERSION are the k8s versions. Any update to the build line could potentially require an update to the sed
# command in generate_k8s_version_commit() in hack/update_submodules.sh
KUBELET_GIT_VERSION=v1.26.0+feedbee
-KUBE-PROXY_GIT_VERSION=v1.26.0+feedbee
+KUBE-PROXY_GIT_VERSION=v1.25.1+72939b9

# CHANNELS define the bundle channels used in the bundle.
# Add a new line here if you would like to change its default config. (E.g CHANNELS = "preview,fast,stable")

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.

[aravindhp]

/test vsphere-e2e-operator

[saifshaikh48]

/lgtm

This approach seems best given it's basically what happens on the Linux side. We just have to remember to make the Dockerfile changes in gitlab midstream as well.

[saifshaikh48]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sebsoto

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sebsoto]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD ce86a24 and 2 for PR HEAD 60c4b4b in total

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD f5b4cb9 and 1 for PR HEAD 60c4b4b in total

[aravindhp]

/test aws-e2e-ccm-install

Seeing:

level=error msg=Error: creating EC2 Instance: InvalidNetworkInterface.InUse: Interface: [eni-0c4821fe74867606b] in use.
level=error msg=	status code: 400, request id: 56e8a02f-22c7-44d1-b650-184d48a962b9 

Known issue: OCPBUGS-887

[aravindhp]

/test aws-e2e-upgrade

Seeing the DaemonSet scaling issue that @sebsoto is debugging with #1404

[aravindhp]

/test aws-e2e-ccm-install

Seeing:

level=error msg=Error: error reading Main Route Table Association (rtbassoc-09b34145658d6477e): empty result

Known issue: OCPBUGS-4005

[aravindhp]

/test aws-e2e-upgrade

Seeing WMCO subscribe fail:

  - message: 'failed to populate resolver cache from source certified-operators/openshift-marketplace:
      failed to list bundles: rpc error: code = Unavailable desc = connection error:
      desc = "transport: Error while dialing dial tcp 172.30.3.86:50051: connect:
      connection refused"'
    reason: ErrorPreventedResolution
    status: "True"
    type: ResolutionFailed

We have seen this error before and hopefully it is transient.

[aravindhp]

/test aws-e2e-upgrade

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD a0cd7f0 and 0 for PR HEAD 60c4b4b in total

[openshift-ci-robot]

/hold

Revision 60c4b4b was retested 3 times: holding

[aravindhp]

/test aws-e2e-upgrade
/unhold

Hit DaemonSet scaling issue again

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD a0cd7f0 and 2 for PR HEAD 60c4b4b in total

[openshift-ci]

@aravindhp: all tests passed!

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

[openshift-ci-robot]

@aravindhp: All pull requests linked via external trackers have merged:

• openshift/windows-machine-config-operator#1401

Jira Issue OCPBUGS-6635 has been moved to the MODIFIED state.

In response to this:

The openshift/kubernetes repo does not propagate all tags from upstream. Only the X.Y.0 tag is propagated. This causes the Windows kubelet and kube-proxy Z version to lag behind its Linux counterparts. The Linux build of kubelet and kube-proxy figures out the Z version at build time. To do something similar for Windows, we can leverage the hack/update_submodules.sh script which is always used to update the kubelet and kube-proxy submodules. To achieve this, the following changes are made:

• Add kubelet and kube-proxy version variables to the Makefile along with make endpoints
• Call these make endpoints in the Dockerfile
• Update hack/update_submodules.sh to pull upstream tags and generate a commit that updates the Makefile version variables

Now the built binaries will have the correct version encoded in them.

Example version update commit:

commit 8f94380e384218561c8b9c3b4158cf2679d17fce (master-submodule-update-02-08)
Author: Aravindh Puthiyaparambil <redacted>
Date:   Wed Feb 8 09:12:47 2023 -0800

   [build] Update kube-proxy version to v1.25.1+72939b9
   
   This commit was generated using hack/update_submodules.sh

diff --git a/Makefile b/Makefile
index 3cbb0c07..43b55d8a 100644
--- a/Makefile
+++ b/Makefile
@@ -8,7 +8,7 @@ WMCO_VERSION ?= 8.0.0
# *_GIT_VERSION are the k8s versions. Any update to the build line could potentially require an update to the sed
# command in generate_k8s_version_commit() in hack/update_submodules.sh
KUBELET_GIT_VERSION=v1.26.0+feedbee
-KUBE-PROXY_GIT_VERSION=v1.26.0+feedbee
+KUBE-PROXY_GIT_VERSION=v1.25.1+72939b9

# CHANNELS define the bundle channels used in the bundle.
# Add a new line here if you would like to change its default config. (E.g CHANNELS = "preview,fast,stable")

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.

[aravindhp]

/cherry-pick release-4.12

[openshift-cherrypick-robot]

@aravindhp: #1401 failed to apply on top of branch "release-4.12":

Applying: Fix k8s version reporting
Using index info to reconstruct a base tree...
M	Makefile
M	build/Dockerfile
M	build/Dockerfile.base
M	build/Dockerfile.ci
Falling back to patching base and 3-way merge...
Auto-merging build/Dockerfile.ci
CONFLICT (content): Merge conflict in build/Dockerfile.ci
Auto-merging build/Dockerfile.base
CONFLICT (content): Merge conflict in build/Dockerfile.base
Auto-merging build/Dockerfile
CONFLICT (content): Merge conflict in build/Dockerfile
Auto-merging Makefile
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Fix k8s version reporting
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

/cherry-pick release-4.12

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.