* Fixes Readiness Check for statefulsets using partitioned rolling update.
Fixes#11773
This change updates readiness check in ready.go to correctly
account for statefulsets that are utilizing a partitioned upgrade.
These statefulsets only upgrade a subset of the managed pods with each call
to helm upgrade. This causes the upgrade to legitimately hit the condition where
sts.status.CurrentRevision != sts.Status.UpdateRevision which causes helm to mark
the upgrade has failed when in fact it is successful.
This change fixes that behavior to only check when partition is unspecified or 0.
Signed-off-by: Aman Nijhawan <anijhawan@yugabyte.com>
* Adding a unit test to verify that partitioned rolling upgrade for a statefulset works.
Signed-off-by: Aman Nijhawan <anijhawan@yugabyte.com>
---------
Signed-off-by: Aman Nijhawan <anijhawan@yugabyte.com>
Co-authored-by: Aman Nijhawan <anijhawan@yugabyte.com>
The GOARCH here is 386 not i386. This caused a slightly odd test
suite failure on that architecture:
--- FAIL: TestPlatformPrepareCommand (0.00s)
plugin_test.go:45: Expected arg="os-arch", got "linux-s390x"
plugin_test.go:64: Expected arg="os-arch", got "linux-s390x"
Signed-off-by: Dirk Müller <dirk@dmllr.de>
Go 1.20 introduced DNS/CNAME handling changes. This can cause an
IP address represented in hex, oct, etc to be looked up as DNS and
fail. This change introduces a mock DNS resolver.
Note, with the mock resolver, we don't need to use 0x7f000001 any
longer. Keeping because it was already there.
Signed-off-by: Matt Farina <matt.farina@suse.com>
At this time both Go 1.19 and 1.20 are supported. The version
specified in the go.mod file is the minimum version we expect Helm
to be compiled against. This is the oldest supported version to
support environments where others compile Helm. The Helm project
is using Go 1.20 to build Helm itself.
Updating to Go 1.19 also includes dealing with io/ioutil
deprecation and some additional linting issues around staticcheck.
All the staticcheck issues were in test files so linting was
skipped for those.
Signed-off-by: Matt Farina <matt.farina@suse.com>
As the CRDs are installed before the capabilities are gathered, the
current call to invalidate the discovery client is premature and
expensive.
What actually is required is an invalidation of the REST mapper, as
otherwise the Helm install action may later on fail with a `resource
mapping not found` error. More specifically when the caller of the
action is making use of a persisting[1] `RESTClientGetter`.
Which is not something done by the Helm CLI (albeit it could, and this
would potentially save quite some resources?). But is a default
configuration offered by the Helm SDK via `kube.New` when a nil value
is provided as the `getter`.
[1]: https://github.com/kubernetes/cli-runtime/blob/v0.26.2/pkg/genericclioptions/config_flags.go#L118
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
If enabled the registryClient is set using a helper that accepts the TLS
flags. This keeps the client creation consistent accross the different
commands.
Signed-off-by: Soule BA <bah.soule@gmail.com>
If implemented, users will be able to use custom certificates and CA to
while interacting with OCI registries.
Signed-off-by: Soule BA <bah.soule@gmail.com>
Add --cascade=<background|foreground|orphan> option to helm uninstall
Current behaviour is hardcoded to background
Addresses issue: https://github.com/helm/helm/issues/10586
Signed-off-by: MichaelMorris <michael.morris@est.tech>
dependabot[bot]
Aman Nijhawan
wujunwei
Dirk Müller
Matt Farina
Matt Farina
willzgli
Scott Rigby
Hidde Beydals
Craig O'Donnell
Soule BA
Andrew Block
Martin Hickey
xin.li
cpanato
Joe Julian
MichaelMorris
Fish-pro