Kube-state-metrics: Release v1.6.0 tag has deployment using the image v1.5.x

[douglascamata]

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug
/kind feature

What happened:

The release v1.6.0 tag (currently at de19ed4) contains a kubernetes/kube-state-metrics-deployment.yaml that points to the Docker image on tag v1.5.0.

See https://github.com/kubernetes/kube-state-metrics/blob/de19ed4f12d471fccc79f9a9fee73f7c107ecd33/kubernetes/kube-state-metrics-deployment.yaml

I did a quick research and this file was only updated on commit 232624b15d0ea5e3f644c6060472b6cb007c41dd.

This confuses people downloading the zip from the release page and applying the manifests to their clusters.

What you expected to happen:

Have the Docker image tag pointing to a version matching the release.

[tariq1890]

@douglascamata Thanks for pointing that out! I am okay with considering cherry-picking that commit into release-1.6 and getting a patch release out.

I'll defer to @brancz @andyxning @mxinden on their thoughts if this warrants a patch-release.

[brancz]

I’m okay with cherry picking but don’t feel like this needs a release.

[mxinden]

Thanks for reporting that @douglascamata. I am also in favor of just cherry-picking. Can you create the pull request @douglascamata?

[andyxning]

Cherry-picking is needed. A new release it not necessary since it just happens when end users download release zip file.

[douglascamata]

Sorry for the delay, I saw someone already cherry picked the commit into the release-1.6 branch. Will the v1.6.0 release tag be updated? I understand that a new release is unnecessary though.

Let me quickly explain how I stumbled on this issue: we instruct our users to download KSM release zips, extract and install the k8s manifests from there with a simple kubectl appy -f ksm_folder/kubernetes. So I would love to be able to give them the exact same instructions for KSM v1.6.0.

[andyxning]

Will the v1.6.0 release tag be updated? I understand that a new release is unnecessary though.

@douglascamata v1.6.0 release tag should be updated. @mxinden @brancz Could you please take a look at this?

[tariq1890]

/close

This has been fixed by #765

[k8s-ci-robot]

@tariq1890: Closing this issue.

In response to this:

/close

This has been fixed by #765

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.

[douglascamata]

@tariq1890 sorry, but this has not been fixed. The release tag still points to the wrong commit (de19ed4f12d471fccc79f9a9fee73f7c107ecd33). And this is the reason for creating this issue.

Until this file https://github.com/kubernetes/kube-state-metrics/blob/v1.6.0/kubernetes/kube-state-metrics-deployment.yaml doesn't point to the image of KSM v1.6.0, the problem lingers.

The only thing that was updated on #765 was the branch release, named release-1.6.

[tariq1890]

/reopen

[k8s-ci-robot]

@tariq1890: Reopened this issue.

In response to this:

/reopen

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.

[andyxning]

@brancz @mxinden Friendly ping. :)

v1.6.0 release tag should be updated. @mxinden @brancz Could you please take a look at this?

[brancz]

Releases should be immutable, I think changing the tag would be a bad idea, you'll need to wait for the next release, sorry.

[tariq1890]

I agree with @brancz regarding immutability. Honestly, I am okay with a patch release to fix this issue. If the majority is in favour, we could do it. Although, I do understand the arguments against putting out a patch release as well :). No strong opinions regarding this.

However, if we are to stick to our previous decision of not putting out a patch release, then we should close the issue IMO.

[brancz]

I'm not against anyone who wants to put their time in, but I don't think it's worth it. We don't release that infrequently and relying on example manifests of a git tag is questionable practice to begin with.

[douglascamata]

@brancz why is that a questionable practice? Just a reminder, installing from the manifests in the kubernetes folder is recommended by KSM's README. Knowing this, I think it's fair to expect that each release contains manifests matching the released version.

What would be the recommended practice then? My use case is to provide the easiest way possible for customers to install KSM on whatever version they want or need, based on criteria like k8s version.

[brancz]

I think it's fair to expect that each release contains manifests matching the released version.

I agree it's fair to expect that, but we're not breaking immutability for this aspect and will try to not make this mistake again for future releases.

We should indeed be more clear that those manifests are a "quickstart" and in a real production environment you shouldn't go around random repos and just apply manifests. My personal recommendation is to have a git repo that has all your artifacts to deploy, so when a new version of kube-state-metrics comes out you only review the diff, and not everything every time (which you should be doing right now as you don't know what has changed).

My use case is to provide the easiest way possible for customers to install KSM on whatever version they want or need, based on criteria like k8s version.

The kube-state-metrics version is not aligned with the kubernetes version, so I don't understand this argument. With the compatibility matrix we provide you can choose the version to deploy.

Manifests in this repo are maintained on a best effort basis. If this is not clear enough, we should add it to the readme.

[douglascamata]

The kube-state-metrics version is not aligned with the kubernetes version, so I don't understand this argument. With the compatibility matrix we provide you can choose the version to deploy.

That was not an argument, I only wanted to let you know the use case, maybe it could help the discussion.

Manifests in this repo are maintained on a best effort basis. If this is not clear enough, we should add it to the readme.

I totally agree with this. The way the README is written right now it looks like those manifests are the way to deploy KSM. If that's not the case, I also agree with your proposed solution.

[brancz]

Ok, then let's adapt the readme, thanks for the feedback! :)