The charts in the manifests directory are used in istioctl to generate an installation manifest. The configuration settings contained in values.yaml files and passed through the CLI are validated against a schema. Whenever making changes in the charts, it's important to follow the below steps.
Is this a new parameter being added? If not, go to the next step. Dynamic, runtime config that is used to configure Istio components should go into the MeshConfig API. Values.yaml is being deprecated and adding to it is discouraged. MeshConfig is the official API which follows API management practices and is dynamic (does not require component restarts). Exceptions to this rule are configuration items that affect K8s level settings (resources, mounts etc.)
manifests directoryThe values.yaml in manifests are only used for direct Helm based installations, which is being deprecated. If any values.yaml changes are being made, the same changes must be made in the manifests/profiles/default.yaml file, which must be in sync with the Helm values in manifests.
Istioctl uses a schema to validate the values. Any changes to the schema must be added here, otherwise istioctl users will see errors. Once the schema file is updated, run:
$ make operator-proto
This will regenerate the Go structs used for schema validation.
Tests of istioctl use the auto-generated manifests to ensure that the istioctl binary has the correct version of the charts. These manifests can be found in gen-istio.yaml. To regenerate the manifests, run:
$ make gen
The new charts/values will likely produce different installation manifests. Unit tests that expect a certain command output will fail for this reason. To update the golden output files, run:
$ make refresh-goldens
This will generate git diffs in the golden output files. Check that the changes are what you expect.
Your PR should pass all the checks if you followed these steps.