There are cases when the etcdserver is temporarily unavailable and the
errors that we get back from kube-apiserver reflect that error. It looks
like we bail out immediately when these errors happen currently. We
should retry until timeout is reached when this sort of errors happen.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
Unfortunately errors from the API server do not always (do they ever?) contain
the name of the resource in question.
Deletions for multiple resources are processed concurrently, so in a resulting
log, a preceding "Starting delete" line might be for a different object.
Signed-off-by: Marcin Owsiany <porridge@redhat.com>
Go passes x509 verification off to the platform and different
platforms provide different responses. The Go tests for x509
even have different test files for different platform providers
that check for different messages.
This update haldes darwins difference for x509 authority handling
Closes#11159
Signed-off-by: Matt Farina <matt@mattfarina.com>
Confirm that the current and updated revision numbers also match as part
of the readiness check. Add coverage for readiness scenarios where
StatefulSet status does not reflect the most recent generation of the
StatefulSet yet.
Also add additional logging around the sts transitions from non-ready to
ready.
Fixes: #10163
Signed-off-by: Dominic Evans <dominic.evans@uk.ibm.com>
Add a new flags and associated environment variables to override
the TLS Settings used when constructing the Kube Client.
- `--kube-insecure-skip-tls-verify | HELM_KUBEINSECURE_SKIP_TLS_VERIFY`: if true, the kube api server's certificate will not be checked for validity. This will make your HTTPS connections insecure
- `--kube-tls-server-name | HELM_KUBETLS_SERVER_NAME`: server name to use for kube api server certificate validation. If it is not provided, the hostname used to contact the server is used
Signed-off-by: Justen Walker <justen.walker+github@gmail.com>
* feat: add configuration for client-side throttling limit
Client-side throttling seems to be an issue in larger environments such as OpenShift clusters, where
it is common to have several hundreds CRDs out-of-the-box.
From this view point, it is fair that clients should be able to fine tune this accordingly should the
environment they work on evolves, which is currently not possible, and quite frustrating.
This change introduces the --default-burst-limit option to helm (and its counterpart
HELM_DEFAULT_BURST_LIMIT environment variable) to address that issue, allowing clients to properly
tune their client usage as their environment evolves.
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
* chore: change DefaultBurstLimit to BurstLimit
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
* chore: add HELM_BURST_LIMIT to golden file
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
* chore: add burst limit tests
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
* docs: add burst limit default value to documentation
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
* refactor: change burst limit default value to 100 per review instructions
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
This required modifying the `kube.Factory` interface to conform to
changes in k8s' `cmdutil.Factory` interface:
fe3772890f
Signed-off-by: Andrew Seigner <andrew@sig.gy>
