[DND-1418] Upgrade Default S3Proxy to 3.x (appVersion 2.7.0 -> 3.3.0) - #25
Merged
Conversation
Bump appVersion to 3.3.0 (latest stable; the chart was several releases behind on 2.7.0). Validated on kind that every functionally-tested backend starts and serves on the 3.3.0 image: s3, filesystem, transient, azureblob (azureblob-sdk), and the multi-backend routing scenario all pass. CI runs the functional legs against the default image tag, which now equals appVersion 3.3.0. Also document S3Proxy version compatibility in the chart README: minimum supported 2.7.0, and the jclouds deprecation path introduced in 3.0.0 (the jclouds providers still work on 3.x but are deprecated; 3.3.0 is the last release to bundle jclouds, after which b2 and rackspace-cloudfiles have no SDK successor). Chart version 0.1.0 -> 0.2.0 (minor: new app major version supported, no breaking chart-values changes). Scope: minimal bump only. Migrating the chart's default providers to their SDK/NIO2 replacements (aws-s3-sdk, google-cloud-storage-sdk, openstack-swift-sdk) and end-of-lifing b2/rackspace is tracked as a separate follow-up.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
….3.0 README: replace the compatibility note with our actual plan. Frame the jclouds sunset as upstream's announced intent (only Atmos and B2 are explicitly named; no jclouds-free release has shipped yet), stop over-claiming that rackspace breaks (it is Swift-compatible and may be served by openstack-swift-sdk), and state the plan: support through 3.3.0 on 0.x, hard-fail if a no-successor jclouds backend is used past 3.3.0, and move the chart to 1.x.x when S3Proxy ships its first jclouds-free release. configmap.yaml: add a render-time guardrail. If b2 (or atmos, if ever added) is enabled while the effective S3Proxy version (image.tag, else appVersion) parses as semver and is > 3.3.0, fail with an actionable message. Non-semver tags (master, sha-*) are not version-checked; 3.3.0 and earlier are allowed. Verified: default renders clean; b2 + image.tag=3.4.0 fails with the message; b2 on 3.3.0 / non-semver tags / non-jclouds backends all render; helm lint, kubeconform (all test-values), and helm-polish (0 errors) clean.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
CRThaze
changed the title
On S3Proxy 3.x the legacy jclouds azureblob provider is deprecated and mis-signs against custom endpoints (Azurite, Azure Gov/China, private endpoints); azureblob-sdk (Azure SDK) is the non-deprecated, correctly-signing provider. Change the chart default provider from "azureblob" to "azureblob-sdk". Users can still set provider: azureblob explicitly for the legacy backend until it is removed post-3.3.0. On real Azure, azureblob-sdk may require config.backends.azureblob.regions for bucket creation (see DND-1416). Update the README compatibility note accordingly. Verified: default azureblob render now emits jclouds.provider=azureblob-sdk; helm lint, kubeconform (all test-values), helm-polish (0 errors) clean.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Add comet-ml/common-helm-chart (comet-common 0.3.0) as a library dependency and
route the chart's helpers through it, so naming, labels, and image rendering
stay consistent with the other Comet charts. The dependency is vendored in-repo
(Chart.lock + charts/comet-common-0.3.0.tgz) so CI and fork PRs resolve it
without any registry access, preserving the no-secrets model.
- _helpers.tpl: s3proxy.name/fullname/chart/serviceAccountName now wrap
comet-common.names.*; s3proxy.labels wraps comet-common.labels.base.
- deployment.yaml: both image strings render via comet-common.images.image.
- s3proxy.selectorLabels kept local (sourcing the name from comet-common) so the
immutable Deployment selector stays {name, instance}; comet-common's
selectorLabels would add app.kubernetes.io/component and break upgrades.
Render is equivalent: names, selector labels, and image strings are byte-identical
to before; the only change is metadata label key ordering (comet-common's order)
and the resulting checksum/config|secret annotation recompute. No
app.kubernetes.io/component is introduced anywhere.
Verified: render diff vs base is label-order + checksum only; helm lint,
kubeconform (all test-values), helm-polish (0 errors) clean; kind install
resolves the vendored dep, renders image andrewgaul/s3proxy:3.3.0, and
multi-backend routing passes.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…ers)
The s3proxy.name/fullname/chart/serviceAccountName/labels wrappers only
delegated to comet-common with no added logic. Remove them and call the
comet-common helpers directly at every call site
(comet-common.names.*, comet-common.labels.base).
_helpers.tpl now keeps only s3proxy.selectorLabels, which does add value: it
pins the immutable Deployment selector to {name, instance} (sourcing the name
from comet-common) rather than comet-common.selectorLabels, which appends
app.kubernetes.io/component.
Pure refactor: render is byte-identical to the previous commit across all 11
test-values (0 unexpected diff lines); helm lint, kubeconform, helm-polish all
clean.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Git-ignore charts/s3proxy/charts/ and stop checking in the resolved comet-common-0.3.0.tgz. Chart.lock (committed) pins the version/digest, and each workflow that renders, installs, or packages the chart now runs `helm dependency build charts/s3proxy` first. comet-common's OCI package is anonymously pullable, so this needs no registry auth and still works on fork PRs. - .gitignore: ignore charts/s3proxy/charts/. - lint-render / functional-test / release: add a "Build chart dependencies" step after Set up Helm (release also gains a Set up Helm step). - helm-diff: build deps for whichever side (base/head) has a Chart.lock before rendering (base may predate the dependency). Verified: removing the local .tgz and running `helm dependency build` from Chart.lock repopulates it and the chart renders; actionlint clean on the changed render/install workflows; helm-polish clean.
📊 Helm Render Diff SummaryChart
🔍 Detailed Changes📝 Changes in
|
📝 README.md PreviewThe following changes to Click to expand diffdiff --git a/README.md b/README.md
index 79b854b..6d94a16 100644
--- a/README.md
+++ b/README.md
@@ -1,15 +1,38 @@
# s3proxy
-  
+  
A Helm chart for deploying S3Proxy - Access other storage backends via the S3 API
+## Requirements
+
+| Repository | Name | Version |
+|------------|------|---------|
+| oci://ghcr.io/comet-ml | comet-common | 0.3.0 |
+
## Prerequisites
- Kubernetes 1.19+
- Helm 3.2.0+
- PV provisioner support in the underlying infrastructure (if using filesystem backend with persistence)
+## S3Proxy version compatibility
+
+The chart tracks S3Proxy (`andrewgaul/s3proxy`) through `appVersion` (currently `3.3.0`); override it with `image.tag`. Minimum supported version is `2.7.0`.
+
+S3Proxy `3.0.0` deprecated the Apache jclouds storage backends (`s3`, `aws-s3`, `azureblob`, `filesystem`, `transient`) in favor of SDK / NIO2 providers. Upstream has announced that `3.3.0` is the last release to bundle jclouds and that future releases "will lack its Atmos and B2 storage backends" (no jclouds-free release has shipped yet; `3.3.0` remains the latest). The jclouds providers still work on 3.x, but are deprecated:
+
+- `filesystem` / `transient`: already default to the non-deprecated `*-nio2` variants (`nio2: true`).
+- `azureblob`: **defaults to `provider: azureblob-sdk`** (the Azure SDK provider, which signs correctly against custom endpoints such as Azurite). The legacy jclouds `azureblob` provider is deprecated and mis-signs against custom endpoints; set `provider: azureblob` only if you specifically need it. On real Azure, `azureblob-sdk` may require `config.backends.azureblob.regions` for bucket creation.
+- `s3`, `googleCloudStorage`, `openstackSwift`: SDK providers exist upstream (`aws-s3-sdk`, `google-cloud-storage-sdk`, `openstack-swift-sdk`). `rackspaceCloudfiles` is OpenStack-Swift-compatible and may be served by `openstack-swift-sdk`. Migrating the chart defaults to the SDK providers is tracked separately.
+- `b2` (and Atmos, if ever added) are jclouds-only with **no SDK successor**. These are the backends upstream has said future releases will drop.
+
+### Our compatibility plan
+
+- **Through S3Proxy `3.3.0` (chart `0.x`):** all current backends, including the jclouds-only `b2`, are supported. This is where the chart sits today.
+- **Guardrail:** the chart **hard-fails at render time** if `b2` (or `atmos`) is enabled while the effective S3Proxy version (`image.tag`, else `appVersion`) is greater than `3.3.0`, so an upgrade past the jclouds sunset cannot silently ship a broken backend. Pin `image.tag` to `3.3.0` or earlier, or disable the backend.
+- **When S3Proxy ships its first jclouds-free release:** the chart moves to `1.x.x` (major bump), migrates the remaining backends to their SDK providers, and drops `b2`/`atmos`. Tracked in the SDK-migration follow-up.
+
## Installation
### Install the chart
@@ -136,9 +159,9 @@ The following section lists the configurable parameters of the s3proxy chart and
</tr>
<tr>
<td><code>config.backends.azureblob.provider</code></td>
- <td>Provider type (azureblob or azureblob-sdk)</td>
+ <td>Provider type. Defaults to <code>azureblob-sdk</code> (Azure SDK): it signs correctly against custom endpoints (Azurite, Azure Gov/China, private endpoints) and is the non-deprecated provider on S3Proxy 3.x. The legacy jclouds <code>azureblob</code> provider is deprecated upstream and mis-signs against custom endpoints; on real Azure <code>azureblob-sdk</code> may require <code>regions</code> to be set for bucket creation.</td>
<td><code>string</code></td>
- <td><code>"azureblob"</code></td>
+ <td><code>"azureblob-sdk"</code></td>
</tr>
<tr>
<td><code>config.backends.azureblob.regions</code></td>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The chart pinned
appVersion: 2.7.0while upstream S3Proxy is at 3.3.0. This bumps to the latest stable and documents the version compatibility story, since 3.x changes the storage-backend provider landscape.Change
Chart.yaml:appVersion2.7.0to3.3.0; chartversion0.1.0to0.2.0.values.yaml: the azureblob backend now defaults toprovider: azureblob-sdk(was the deprecated jcloudsazureblob). The Azure SDK provider signs correctly against custom endpoints; setprovider: azureblobonly if you specifically need the legacy one.configmap.yaml: render-time guard that hard-fails if a no-SDK-successor jclouds backend (b2, oratmosif ever added) is enabled while the effective S3Proxy version (image.tag, elseappVersion) parses as semver and is> 3.3.0.README.md.gotmpl: "S3Proxy version compatibility" section documenting the plan (support through 3.3.0 on chart 0.x; the guardrail; move to 1.x.x when a jclouds-free S3Proxy release ships).Validation
Ran the full functional matrix against
image.tag=3.3.0on kind. All backends start and serve:s3(jclouds)filesystem-nio2transient-nio2azureblob-sdkThe chart's default image tag equals
appVersion, so the PR's own functional CI legs re-run against 3.3.0 automatically.helm lint,kubeconform -strict(all test-values), andhelm-polish(0 errors) are clean.Compatibility note
S3Proxy 3.0.0 deprecated the Apache jclouds backends (
s3,aws-s3,azureblob,filesystem,transient) in favor of SDK/NIO2 providers. Upstream has announced that 3.3.0 is the last release to bundle jclouds and that future releases "will lack its Atmos and B2 storage backends" (no jclouds-free release has shipped yet, 3.3.0 is still latest, and only Atmos and B2 are explicitly named). The jclouds providers still work on 3.x (validated above):filesystem/transientalready default to the non-deprecated*-nio2variants.azureblobnow defaults toazureblob-sdk; the legacy jcloudsazureblobis deprecated and mis-signs against custom endpoints. On real Azure,azureblob-sdkmay needconfig.backends.azureblob.regionsset.s3,googleCloudStorage,openstackSwifthave SDK successors upstream (aws-s3-sdk,google-cloud-storage-sdk,openstack-swift-sdk);rackspaceCloudfilesis OpenStack-Swift-compatible and may run onopenstack-swift-sdk.b2(and Atmos, if added) are jclouds-only with no SDK successor; these are the backends upstream said future releases will drop. The render guard blocks them when the effective version is> 3.3.0.Plan: support through 3.3.0 on chart
0.x; move to1.x.xand migrate/drop the jclouds backends when S3Proxy ships its first jclouds-free release. The SDK-provider migration is tracked in DND-1447.comet-common library dependency
Adds
comet-ml/common-helm-chart(comet-common0.3.0) as a library dependency and routes this chart's helpers through it, so naming, labels, and image rendering stay consistent across Comet charts.charts/s3proxy/charts/is git-ignored.Chart.lock(committed) pins the version/digest, and each workflow that renders, installs, or packages the chart runshelm dependency build charts/s3proxyfirst (lint-render, functional-test, helm-diff, release). comet-common's OCI package is anonymously pullable, so this needs no registry auth and still works on fork PRs.comet-common.names.*(name/fullname/serviceAccount) for names,comet-common.labels.basefor labels, andcomet-common.images.imagefor both image strings. No thin s3proxy pass-through wrappers remain.s3proxy.selectorLabelsis the one helper kept local (it adds value): it pins the Deployment selector to{name, instance}(name sourced from comet-common).comet-common.selectorLabelsaddsapp.kubernetes.io/component, andspec.selector.matchLabelsis immutable, so adopting it would breakhelm upgradeon existing releases.checksum/config/checksum/secretannotation recompute. Noapp.kubernetes.io/componentis introduced. Verified end-to-end on kind (dependency resolves, image rendersandrewgaul/s3proxy:3.3.0, multi-backend routing passes).Notes