update dependencies to latest version

[humblec]

Fix #206

Signed-off-by: Humble Chirammal hchiramm@redhat.com

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: humblec

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 [humblec]

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

[humblec]

/assign @yonatankahana

[tkudupudi2]

@humblec will this PR be merged anytime soon?

[humblec]

@yonatankahana can you please review this PR ?

[jackielii]

mostly looks good to me except the image tag change. I'll approve once amended. thanks

[yonatankahana]

@humblec
tested on kubernetes 1.25.3 and it failed to start with the error:

F0411 00:34:32.671804       1 controller.go:878] Error creating lock: endpoints lock is removed, migrate to endpointsleases

seems like it already fixed in sig-storage-lib-external-provisioner (https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner/blob/cabcbb0869a16b267bd3c260c70d976495606526/controller/controller.go#L868) and released in v9.0.0. maybe we should even use v9.0.2 already.

please, test your commits before pushing them...

n.b: we claim to support kubernetes >= 1.9, we must test if it still true after these changes before merge.

[humblec]

@yonatankahana I have updated to v9.0.2 and also tested on 1.26.3 cluster and controller runs.

I0411 09:49:12.421958   17960 leaderelection.go:248] attempting to acquire leader lease default/nfs-provisioner...
I0411 09:49:12.460820   17960 leaderelection.go:258] successfully acquired lease default/nfs-provisioner
I0411 09:49:12.460847   17960 event.go:285] Event(v1.ObjectReference{Kind:"Endpoints", Namespace:"default", Name:"nfs-provisioner", UID:"0b5fa37b-5f24-4f17-aca0-89951b7824aa", APIVersion:"v1", ResourceVersion:"1728", FieldPath:""}): type: 'Normal' reason: 'LeaderElection' myhost_e7f8cb2c-02db-4993-97c3-a92dbfbd9ee3 became leader
I0411 09:49:12.460881   17960 event.go:285] Event(v1.ObjectReference{Kind:"Lease", Namespace:"default", Name:"nfs-provisioner", UID:"a32d59b0-6dff-4657-bdfa-ad7f60e0de8e", APIVersion:"coordination.k8s.io/v1", ResourceVersion:"1729", FieldPath:""}): type: 'Normal' reason: 'LeaderElection' myhost_e7f8cb2c-02db-4993-97c3-a92dbfbd9ee3 became leader
I0411 09:49:12.460924   17960 controller.go:811] Starting provisioner controller nfs-provisioner_myhost_e7f8cb2c-02db-4993-97c3-a92dbfbd9ee3!
I0411 09:49:12.562042   17960 controller.go:860] Started provisioner controller nfs-provisioner_myhost_e7f8cb2c-02db-4993-97c3-a92dbfbd9ee3!

n.b: we claim to support kubernetes >= 1.9, we must test if it still true after these changes before merge.

I don't see any point to support versions really OLD! these Kubernetes versions ( v1.9 to v1.23) are not even supported from the community, even if we think about some kind of extended support from a specific distro/vendor may be a couple of versions could be added to n-3 , but v1.9 to 1.21 support looks an unwanted claim!

[humblec]

@yonatankahana @jackielii can we get this in ?

[yonatankahana]

@humblec

I don't see any point to support versions really OLD! these Kubernetes versions ( v1.9 to v1.23) are not even supported from the community, even if we think about some kind of extended support from a specific distro/vendor may be a couple of versions could be added to n-3 , but v1.9 to 1.21 support looks an unwanted claim!

i agree, but we must understand what those changes means in terms of backward compatibility, those are probably breaking changes....
we also need to update the documentation and helm charts kubeVersion constraint accordingly.

[bman46]

Any updates on this?

[humblec]

@humblec

I don't see any point to support versions really OLD! these Kubernetes versions ( v1.9 to v1.23) are not even supported from the community, even if we think about some kind of extended support from a specific distro/vendor may be a couple of versions could be added to n-3 , but v1.9 to 1.21 support looks an unwanted claim!

i agree, but we must understand what those changes means in terms of backward compatibility, those are probably breaking changes.... we also need to update the documentation and helm charts kubeVersion constraint accordingly.

@yonatankahana users are free to use the existing version of provisioner if they want to stick to old or if they are facing issue with latest version of the provisioner in VERY OLD clusters. The new clusters can definitely use the provisioner which has been updated.. Also I don't think any user still exist with versions like Kube v1.9 or something below v1.23 ( ie 4 releases back to latest) . However, I have placed the version as 1.21 and above. With that I don't see a point to blocking this PR from the merge. I have updated the readme and chart definition to reflect the same. please take a look.

[yonatankahana]

only version should be bumped, appVersion is the image tag (4.0.2)

[humblec]

It was deliberate , so that, the image ( tag) remain consistent for older deployment.. the upgrade can be version and image update to really land on new versions. @yonatankahana .

[yonatankahana]

@humblec

I don't see any point to support versions really OLD! these Kubernetes versions ( v1.9 to v1.23) are not even supported from the community, even if we think about some kind of extended support from a specific distro/vendor may be a couple of versions could be added to n-3 , but v1.9 to 1.21 support looks an unwanted claim!

i agree, but we must understand what those changes means in terms of backward compatibility, those are probably breaking changes.... we also need to update the documentation and helm charts kubeVersion constraint accordingly.

@yonatankahana users are free to use the existing version of provisioner if they want to stick to old or if they are facing issue with latest version of the provisioner in VERY OLD clusters. The new clusters can definitely use the provisioner which has been updated.. Also I don't think any user still exist with versions like Kube v1.9 or something below v1.23 ( ie 4 releases back to latest) . However, I have placed the version as 1.21 and above. With that I don't see a point to blocking this PR from the merge. I have updated the readme and chart definition to reflect the same. please take a look.

@humblec imo if it's compatible there is no reason to restrict installation on old clusters. I myself still maintaining more than 20 clusters with the nfs subdir external provisioner installed on kubernetes v1.17 and I will be very happy to get those trivy CVE's resolved. I do agree that we don't need to actively support such old versions but why just change the version arbitrarily? why not check it fully? where are we rushing to?

nothing is blocked, such big changes require deep look, i can't just merge 1.3k lines patches. look how much changes done since PR created. it takes time - we all volunteer in our free time 😃

tbh, i will feel much safer to merge #287 to solve the original issue, release a new version, and only then merge this PR.
we can, tomorrow, release a 100% compatible version with 2 years of bugs and CVE's resolved. after that we can break whatever we want.

[yonatankahana]

changing the version will cause chart release, better to change the kubeVersion only when we will actually release the chart with those restrictions, currently it will be redundant since image and chart are same.

[humblec]

new chart release was the plan with new image tag as mentioned above. so that the versions remain different and users can upgrade when they want.

[humblec]

tbh, i will feel much safer to merge #287 to solve the original issue, release a new version, and only then merge this PR.
we can, tomorrow, release a 100% compatible version with 2 years of bugs and CVE's resolved. after that we can break whatever we want.

I am fine to merge 287 and release new version. However the justifications for keeping this PR in queue for long time does not look good to me :), any way, we will get this in on top of 287 and a new release. 👍

[k8s-ci-robot]

PR needs rebase.

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.

[mengjiao-liu]

Please rebase to resolve the conflict.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[cornfeedhobo]

/remove-lifecycle stale

[cornfeedhobo]

This PR is a year old. Can someone open another PR that closes this one, so we can stop dragging this out?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten