`postgresqlPostgresPassword` enables users to set a password for the `postgres` user when `postgresqlUsername` is not `postgres`
Signed-off-by: Sameer Naik <sameersbn@vmware.com>
* allow additional labels for elasticsearch-curator pod and cronjob
Signed-off-by: Brad Clark <bdashrad@gmail.com>
* update configuration guide for elasticsearch-curator
Signed-off-by: Brad Clark <bdashrad@gmail.com>
* fix alignment in readme for elasticsearch-curator
Signed-off-by: Brad Clark <bdashrad@gmail.com>
* velero: Add azure support.
Modified the velero deployment to match the one produced by the velero CLI.
Signed-off-by: Borja Clemente <borja.clemente@gmail.com>
* velero: bump chart version.
Signed-off-by: Borja Clemente <borja.clemente@gmail.com>
* Fix 3 way OR in vleero provider credentials
Signed-off-by: Borja Clemente <borja.clemente@gmail.com>
* Updated version.
Signed-off-by: Michael Hewitt <hmike1996@gmail.com>
* Added preceding path loop in ingress template.
Signed-off-by: Michael Hewitt <hmike1996@gmail.com>
* Added documentation for feature in readme and example in values
Signed-off-by: Michael Hewitt <hmike1996@gmail.com>
* Fixed trailing spaces for lint
Signed-off-by: Michael Hewitt <hmike1996@gmail.com>
* Readme example.
Signed-off-by: Michael Hewitt <hmike1996@gmail.com>
* Changed name of paths value to make it more distinct and updated docs.
Signed-off-by: Michael Hewitt <hmike1996@gmail.com>
* [stable/prometheus-blackbox-exporter] Update the Ingress apiversion to networking.k8s.io/v1beta1
Signed-off-by: Mike Tougeron <tougeron@adobe.com>
* [stable/prometheus-blackbox-exporter] toggle the apiVersion based on the version of k8s you are using
Signed-off-by: Mike Tougeron <tougeron@adobe.com>
* Introduce crds directory for compatibility with Helm v3
- This adds `crds` directory which has all 5 CRDs
- As files from crds directory needs to be plain YAMLs, keeps
app: prometheus-operator label and removes all the templating
- With this change `.Values.prometheusOperator.createCustomResource`
will be ignored by Helm v3 as it handles the CRDs differently. Which
means, if the CRDs already present in the cluster then it won't
touch them at all
- Helm v3 ignores the objects from `templates` directory which have a
`crd-install` hook
- Update the README.md
- Update the chart version
Signed-off-by: Bhavin Gandhi <bhavin7392@gmail.com>
* Use files from crds directory to generate CRDs for Helm v2
- Deletes the templates/prometheus-operator/crd-*.yaml
- Adds templates/prometheus-operator/crds.yaml which generates YAMLs
for CRDs. The hooks from these CRDs are detected by Helm v2 as well
as v3. Helm v2 executes the hook and Helm v3 ignores the hook (YAML
files are not applied)
Signed-off-by: Bhavin Gandhi <bhavin7392@gmail.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/pulls/12642 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/pulls/17305 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/pulls/17297 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>