Create new tracks for ecr-credential-provider snap

store-requests
1

Dear store team,

please create a new tracks for ecr-credential-provider.

1.27.9
1.28.9
1.29.6
1.30.3

Thank you,

2

Hi Jessica,

I would like some more information about these tracks.

Backward (in)compatibility is typically a good use case for tracks. Can you provide more information about the track names and how those numbers map to major/minor/patch releases?

For example, 1.27.9, 1.28.9, and so on, look like patch versions. Will there be a 1.27.10? Is that backward-incompatible with 1.27.9? Perhaps you need 1.31 track instead to encompass all following changes; this more closely follows the pattern used by by the ecr-credential-provider snap currently.

Please let me know your thoughts on creating a 1.31 track instead.

Thanks, Emma

3

Hello Emma!

ecr-credential-provider is kubernetes integration tool for different cloud platform. (Please see here). And yes, there will be 1.27.10 and other patch versions as long as there is new release for current supported Kubernetes versions. And each version (1.27, 1.28, … ) is designed to work with specific Kubernetes versions (compatibility is not always guaranteed and recommended either).

CPC provides EKS images per version and snaps (kubelet, kubectl, kube-proxy, …) in images should be matched to each kube version.

The pattern we used for ecr-credential-provider was updating to the stable directly (no matter of patch version) but it has risk that current users deployment can be broken when they update snap. By tracking separate patches, we can make sure to test updated patches and publish new images to customers safely.

Thanks,

4

Also,

Could we please have track guardrails for ecr-credential-provider snap?

The tracks should match the previous releases, e.g., 1.30.0 or 1.29.7. Therefore the regex for the guardrail should be ^\d{1,2}\.\d{1,2}\.\d{1,2}.

Thanks!

5

Hi Jessica,

We reserve new tracks for versions that are incompatible with each other. From what you are saying I’m gathering that the minor versions (1.27, 1.28, …) and not the patches (1.27.9, etc) are incompatible with each other.

Creating a track for every new patch version will lead to fragmentation of the user base. I think this case should be handled with new minor tracks, and the patch versions handled as updates on the tracks.

Emma

6

Hi,

the patch versions are not incompatible. But ecr-credential-provider is used within AWS EKS worker nodes (those are kubernetes worker nodes) and usually people expect to not have inplace upgrades. Instead a worker node gets replaced by another node. That other node uses a newer image which contains a updated version of the ecr-credential-provider. Note that this is also used for other snaps in those worker nodes. Eg. kubelet-eks and kubectl-eks. Both track patch versions.

7

Thank you both for you explanations.

Due to the fact that this precedence was set with other eks related snaps, I think it makes sense to continue with the pattern.

I have added the followed tracks to snap ecr-credential-provider:

1.27.9

1.28.9

1.29.6

1.30.3

When a guardrail is created, all subsequent tracks must follow that pattern. If I implement the suggested guardrail of ^\d{1,2}\.\d{1,2}\.\d{1,2}, then all following tracks must have a patch version. Before I implemented that, I wanted to ensure that this was the intended behavior.

Please confirm if this is the case.

Thanks

Emma

8

Yes, please create guardrails with that regex including patch version. Thanks!

9

I’ve created the guardrail. Thanks!