[bot] Bump openshift/kube-state-metrics to v2.14.0

[openshift-monitoring-bot]

Description

This is an automated version bump from CI.
The logs for this run can be found in the syncbot repo actions.
If you wish to perform this manually, execute the following commands from openshift/kube-state-metrics repo:

git fetch https://github.com/kubernetes/kube-state-metrics --tags
if ! git merge refs/tags/v2.14.0 --no-edit; then
  git checkout --theirs CHANGELOG.md .github/ Dockerfile docs/ go.mod

  git checkout --ours OWNERS
  git add CHANGELOG.md .github/ Dockerfile docs/ go.mod
 OWNERS
  git merge --continue
fi
go mod tidy
go mod vendor

if [ -f scripts/rh-manifest.sh ]; then
  bash scripts/rh-manifest.sh
  git add rh-manifest.txt
  git diff --cached --exit-code || git commit -s -m "[bot] update rh-manifest.txt"
fi

[openshift-ci]

Hi @openshift-monitoring-bot[bot]. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: openshift-monitoring-bot[bot]
Once this PR has been reviewed and has the lgtm label, please assign rexagod for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[simonpasquier]

/ok-to-test

[simonpasquier]

/hold
@rexagod the image build fails with

make: gomplate: No such file or directory
go: go.mod requires go >= 1.23.0 (running go 1.22.7; GOTOOLCHAIN=local) 

[simonpasquier]

Note that we don't have (yet) Go 1.23 in OCP 4.19 but it should happen soon. Maybe we should just wait it.

[openshift-ci]

@openshift-monitoring-bot[bot]: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/okd-scos-e2e-aws-ovn	b929440	link	false	/test okd-scos-e2e-aws-ovn

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

[rexagod]

Since we have openshift/release:rhel-9-release-golang-1.23-openshift-4.19 now, I believe this can be merged, since the gomplate error should be addressed after AOS picks up the newer Dockerfile that does make install-tools followed by make build-local, which should address this: kubernetes#2572 (comment).

[rexagod]

Also this bug was initially present in v2.13 and fixed in v2.14.

/cc @simonpasquier @jan--f
For an LGTM.

[machine424]

Actually you only came across the gomplate issue because of the go versions mismatch. the gomplate command not being present issue is silent.
Downstream, we're using Dockerfile.ocp that isn't touched in this PR and the build is passing even though the command isn't present, see https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_kube-state-metrics/117/pull-ci-openshift-kube-state-metrics-master-images/1865194155924262912/artifacts/build-logs/kube-state-metrics-amd64.log

AFAIU, adjusting Dockerfile.ocp to install the tools will require to vendor them and I don't know how it's easy to do and maintain that downstream vs maintaining our own Makefile with a fix like yours kubernetes#2572, I don't see why it was decided to install all the tools even though we can do without them (I don't have the whole context though)

(upstream, It would be great to have such scripts fail instead of just logging errors.)

/hold

[rexagod]

There was no Golang version mismatch, but the make logs in the build that caught my eye,

2024-12-07T00:47:38.626398388Z make: gomplate: No such file or directory
2024-12-07T00:47:38.699561059Z make: gomplate: No such file or directory

Ah, you mean for this PR to be held off? Yeah this could've been merged if not for that.

But I want to point out that even if this was merged, it will cause the ART bot to pick-up the Dockerfile here and use that to reconcile the Dockerfile (for the latest Golang version injection). None of this requires vendoring as the dependencies are installed at $GOBIN.

So it should smooth out automatically? WDYT?

[machine424]

Besides of updating some tags, I'm not sure the bot would update Dockerfile.ocp to make it run RUN make install-tools && make build-local as in Dockerfile.

In air gabbed envs, go will not be able to download anything and we have no guarantee those tools are in the $GOBIN of the building image/container, we should assume there is nothing in there.

[rexagod]

Besides of updating some tags, I'm not sure the bot would update Dockerfile.ocp to make it run RUN make install-tools && make build-local as in Dockerfile.

The bot will only update the image URIs, but on top of the existing Dockerfile in the repository, which after this patch will be updated to the one included in this PR.

In air gabbed envs, go will not be able to download anything and we have no guarantee those tools are in the $GOBIN of the building image/container, we should assume there is nothing in there.

If this was true for the building image, the CI in KSM would fail. Additionally, there is no reason to assume ART's official images will somehow prohibit the existence of $GOBIN, as these dependencies are downloaded in the same manner as all other ones listed in the root go.mod.

[rexagod]

Actually, this uses the same mechanism as seen in tools: https://github.com/openshift/cluster-monitoring-operator/blob/master/hack/tools/tools.go, so its safe to assume this is good (more here)? But LMK if I'm missing something.

[machine424]

The bot will only update the image URIs, but on top of the existing Dockerfile in the repository, which after this patch will be updated to the one included in this PR.

I don't think any bot sync Dockerfile.ocp from Dockerfile.

If this was true for the building image, the CI in KSM would fail. Additionally, there is no reason to assume ART's official images will somehow prohibit the existence of $GOBIN, as these dependencies are downloaded in the same manner as all other ones listed in the root go.mod.

As I mentioned in #117 (comment) the failure is silent (doesn't change the exit code), we can see 2024-12-07T00:47:38.708492964Z make: gomplate: No such file or directory in https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_kube-state-metrics/117/pull-ci-openshift-kube-state-metrics-master-images/1865194155924262912/artifacts/build-logs/kube-state-metrics-amd64.log but the build is still successful.

As I mentioned, in some envs (air gabbed ones), nothing can be downloaded from the internet, everything should come from vendor/

[rexagod]

I should've clarified this was for cases where only Dockerfile exists in the repository and also is the one used in openshift/release workflows. This is true for CMO, but not for KSM (as it has a Dockerfile.ocp).

The "airgapped" comment makes sense, as CMO and its assets (which the bot vendors on bumps) are all vendored. I'll have to assume the builder expects no dependency downloads, whether its CPaaS or Konflux. Based on this assumption, I'll cut a release with my aforementioned PR that I closed earlier.

kubernetes#2572 (comment)

[machine424]

yes, it'll be great if we don't have to vendor those tools (less CVEs to worry about as well ;))
also, if we could have a set -e like mode on those commands upstream to avoid such silent failures next time, it'd be great.