Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17307 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17304 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17303 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17352 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17295 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17285 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17300 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17302 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17298 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17301 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17299 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
* Should leave getambassador.io/config uncommented to avoid confusion
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* Redis is required for Ambassador Pro not just rl
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* move crds to individual files in single dir
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* Make crds.keep: false functional again
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* crds.keep: false now works on pro
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* bump chart version
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* Only the release that creates crds can delete
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* add ci test for crds creation/deletion
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* Add clarification to values.yaml
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* Update readme with notes on the crds flags
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* trailing spaces are dumb
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* fix startup error
Signed-off-by: Noah Krause <krausenoah@gmail.com>
* Fix Readme based on sysCtl change
Signed-off-by: Philippe Dagenais <pgdagenais@gmail.com>
* Bump chart version
Signed-off-by: Philippe Dagenais <pgdagenais@gmail.com>
* Bump chart version after sync with master
Signed-off-by: Philippe Dagenais <pgdagenais@gmail.com>
* Bump redis exporter version to the lastest version
Signed-off-by: Philippe Dagenais <pgdagenais@gmail.com>
* [stable/k8s-spot-termination-handler] Add missing 'namespace'
The 'namespace' wasn't set for daemonset and serviceaccount.
Signed-off-by: Kai Forsthövel <kai.forsthoevel@invision.de>
* [stable/k8s-spot-termination-handler] Bump version
Signed-off-by: Kai Forsthövel <kai.forsthoevel@invision.de>
* [stable/k8s-spot-termination-handler] Bump version
Signed-off-by: Kai Forsthövel <kai.forsthoevel@invision.de>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In this version the `apiVersion` of the deployment resources is updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17285 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17294 the `apiVersion` of the deployment resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version bump signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
* [stable/pomerium] Setting Ingress Hosts from policy
The kubernetes-sigs/external-dns create DNS records based on the Hostnames in Ingress objects.
Setting the hostnames explicitly in the Ingress object and not using a wildcard can help to take advantage of this functionality
https://github.com/pomerium/pomerium-helm/pull/32
Signed-off-by: Mohsen <mohsen0@users.noreply.github.com>
* Making .policy mutually exclusive with the ingress.hosts
Signed-off-by: Mohsen <mohsen0@users.noreply.github.com>
The main goal is to allow installation of CRD using separate Helm deployment.
This is an alternative to using separate Helm Chart for CRD deployment.
This is helpfull for example during distaster recovery. When Sealed Secrets installation is broken and need to be reinstalled, the helm tries also to install CRD (if enabled), but when CRD already exists installation fails. This is especially usefull with deployment automation and declarative deployments definitions.
Signed-off-by: Jiri Pinkava <jiri.pinkava@rossum.ai>
This makes it easier to use persistence. As all one needs to do is to
set `persistence.enabled` to `true`
It's still possible to override it with other settings if the user wants
to.
Reasoning for the values:
- `accessMode` needs to be defined anyhow as the template uses it when
rendering the PVC
- `storageClass` of empty uses the default storage class of the cluster
- `size` 10Gi - just a default values
Signed-off-by: Torsten Walter <torsten.walter@syncier.com>
service uses `{{ template "sonarqube.fullname" . }}` as name.
The test should use the same name when trying to access it
Signed-off-by: Torsten Walter <torsten.walter@syncier.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment). Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place. Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17281 the `apiVersion` of the statefulset resources was updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
This major version bump signifies this change.
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Helm performs a lookup for the object based on its group (apps), version (v1), and kind (Deployment).
Also known as its GroupVersionKind, or GVK. Changing the GVK is considered a compatibility breaker
from Kubernetes' point of view, so you cannot "upgrade" those objects to the new GVK in-place.
Earlier versions of Helm 3 did not perform the lookup correctly which has since been fixed to match the spec.
In https://github.com/helm/charts/pull/17308 the `apiVersion` of the statefulset resources was
updated to `apps/v1` in tune with the api's deprecated, resulting in compatibility breakage.
In this PR we have bumped the chart major version to signify this and also added the mariadb.statefulset.apiVersion`
helper that returns the correct `apiVersion` to use depending on the k8s version
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
Sameer Naik
Oleg Khoruzhenko
Aaron Layfield
Luke Shumaker
Noah Krause
Brady Todhunter
Philippe Dagenais
Kai Forsthövel
Naseem
Bitnami Bot
Kai Timmer
Mohsen
Jiří Pinkava
Rafael Ríos Saavedra
Torsten Walter
Alex Moskalenko
Tim Costa
grimmxsleeper
Felippe Mendonça
Valentin Zayash
Tim Jacomb
Xiang Dai
Stephan
Scott McCullough
Damian Myerscough
Pierre Tessier
Tibo Beijen
Miguel Ángel Cabrera Miñagorri