/go/pkg/mod/sigs.k8s.io/sig-storage-lib-external-provisioner/[email protected]/controller/controller.go:868:44: undefined: resourcelock.EndpointsLeasesResourceLock

[adit-cmd]

No description provided.

[jsafrane]

Can you please elaborate more on this error? Esp., what go version do you use and what k8s.io/client-go version does your project use? EndpointsLeasesResourceLock has been deprecated + removed from client-go a while ago.

sig-storage-lib-external-provisioner v9.0.3 uses k8s.io/client-go v0.26.0 that still has it, I would be very careful upgrading to never client-go releases. Use sig-storage-lib-external-provisioner v10 to get k8s.io/client-go v0.30.0 + lease lock as the default one.

[Starttoaster]

I also came across this Issue trying to update some dependencies (including client-go.) Thanks for the context, the error makes total sense now. I updated from v9 to v10 of this library and that compile-time error went away.

Sorry if this is a little off topic. One question I still have about this is: how do I implement leader election in my storage controller code using the latest v10 of this library? I didn't see any mention of leader election in the example, is it handled completely by this library now? I was updating from v6 of this library, where back then I believe you needed to handle leader election outside of the library code to some extent.

edit: It appears this library self-contains all the leader election code now, which is really nice. I'm not the Issue author but in my opinion this Issue is close-able. In both of our cases this is very likely just a naive update to client-go.

[thisisharrsh]

Thanks @Starttoaster for sharing the feedback on upgrading to v10 of the library.

[thisisharrsh]

For others who might be facing the similar issues, i'd like to highlight the some points:

1. when upgrading from the older version to the newer versions, ensure to check the migration guides.
2. as mentioned by @Starttoaster in v10 the leader elections process has been streamlined and includes within the library itself and which simplifying the implementations for the developers.

[thisisharrsh]

Also @adit-cmd, If the issue is resolved now and you have no other issues to continue with, you can close this issue now.

[adit-cmd]

Hi All, thanks @Starttoaster, @jsafrane and @thisisharrsh for the response. I will try to upgrade this library again soon. However as per my experience, im getting stuck in a loop while trying to upgrade this library since the application is dependent on few other modules. Below is the require section.

require (
github.com/aws/aws-sdk-go v1.25.8
github.com/aws/aws-sdk-go v1.34.0
k8s.io/api v0.0.0-20191003000013-35e20aa79eb8
k8s.io/apimachinery v0.0.0-20190913080033-27d36303b655
k8s.io/client-go v0.0.0-20191003000419-f68efa97b39e
k8s.io/klog v1.0.0
sigs.k8s.io/sig-storage-lib-external-provisioner v4.0.1+incompatible
)

So when I am trying to update the apimachinery and client-go to a later version, I am getting stuck in a loop with the below error while trying to build the docker image:
undefined: resourcelock.EndpointsLeasesResourceLock

Any help is appreciated since I am relatively new to handling go upgrades. Thanks.

[thisisharrsh]

@adit-cmd, Could you please describe the issue first that you are facing in the description box, that will be helpful for the other contributors to understand the issue better? 

[thisisharrsh]

undefined: resourcelock.EndpointsLeasesResourceLock

Since resourcelock.EndpointsLeasesResourceLock is no longer available, you'll need to replace it with the newer method of resource locking.

[thisisharrsh]

k8s.io/apimachinery v0.0.0-20190913080033-27d36303b655
k8s.io/client-go v0.0.0-20191003000419-f68efa97b39e

Ensure the versions of k8s.io/client-go and k8s.io/apimachinery are compatible with each other and the rest of your dependencies. sometimes there might be a compatibility issue in your build.

You can also rebuild you docker image and test if everything is working fine.

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 issue is closed

You can:

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

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

/lifecycle stale