The [GitOps Principles](https://opengitops.dev/) guide this reference architecture.  With the exception of [./meta-application.yaml](./meta-application.yaml) (the bootstrap file), Git is the source of truth for all components of our application.  Changes to all components of Istio, including the data plane, are initiated with a pull request.  Likewise, rollbacks are as simple as a revert.

Currently, these steps are pre-configured and built in the deployment. However, each of them could be tested

>
> **Note**
>
> The configurations here are only for Istio deployments, and do not scrape metrics from the Kubernetes components.
> See the [Cluster Monitoring](https://coreos.com/operators/prometheus/docs/latest/user-guides/cluster-monitoring.html) documentation for configuring this.
>
> **Warning**
>

Note: there are still some cluster roles that may need to be fixed, most likely cluster permissions
will need to move to the security component.

## Everything is Optional

Each component in the new installer is optional. Users can install the component defined in the new installer,
use the equivalent component in `istio-system`, configured with the official installer, or use a different
version or implementation.

    - **Pilot** - Responsible for configuring the proxies at runtime.

    - **Citadel** - Responsible for certificate issuance and rotation.

    - **Galley** - Responsible for validating, ingesting, aggregating, transforming and distributing config within Istio.

- **Operator** - The component provides user friendly options to operate the Istio service mesh.

Any changes to this folder should have a `make copy-templates` applied afterwards.

Warning: unlike the `IstioOperator` profiles, these profiles cannot enable or disable certain components.
As a result, users still need to ensure they install the appropriate charts to use a profile correctly.