How to upgrade the Istio ControlPlane Package chart📜

Checkout the branch that renovate created. This branch will have the image tag updates and typically some other necessary version changes that you will want. You can either work off of this branch or branch off of it.
Update the dashboards via kpt. You should be able to run kpt pkg update chart/dashboards@<version> --strategy force-delete-replace (ex: kpt pkg update chart/dashboards@1.14.3 --strategy force-delete-replace).
Update version references for the Chart. version should be <version>-bb.0 (ex: 1.14.3-bb.0) and appVersion should be <version> (ex: 1.14.3). Also validate that the BB annotation for the main Istio version is updated (leave the Tetrate version as-is unless you are updating those images).
Verify that chart/values.yaml tag and tidTAG have been updated to the new version.
Add a changelog entry for the update. At minimum mention updating the image versions.
Update the readme following the steps in Gluon.
Open MR (or check the one that Renovate created for you) and validate that the pipeline is successful. Also follow the testing steps below for some manual confirmations.

Testing new Istio ControlPlane version📜

Generally the controlplane update should be tested alongside the new operator version. Follow the steps below for testing both. You should perform these steps on both a clean install and an upgrade from BB master.

Branch/Tag Config📜

If you’d like to install from a specific branch or tag, then the code block under istio needs to be uncommented and used to target your changes.

For example, this would target the renovate/ironbank branch.

istio:
  <other config/labels>
  ...
  ...

  # Add git branch or tag information to test against a specific branch or tag instead of using `main`
  # Must set the unused label to null
  git:
    tag: null
    branch: "renovate/ironbank"

The istioOperator also needs to be updated.

istioOperator:
  <other config/labels>
  ...
  ...

  # Add git branch or tag information to test against a specific branch or tag instead of using `main`
  # Must set the unused label to null
  git:
    tag: null
    branch: "renovate/ironbank"

Cluster setup📜

⚠️ Always make sure your local bigbang repo is current before deploying.

Export your Ironbank/Harbor credentials (this can be done in your ~/.bashrc or ~/.zshrc file if desired). These specific variables are expected by the k3d-dev.sh script when deploying metallb, and are referenced in other commands for consistency:
```
export REGISTRY_USERNAME='<your_username>'
export REGISTRY_PASSWORD='<your_password>'
```
Export the path to your local bigbang repo (without a trailing /):

⚠️ Note that wrapping your file path in quotes when exporting will break expansion of ~.
```
export BIGBANG_REPO_DIR=<absolute_path_to_local_bigbang_repo>
```
e.g.
```
export BIGBANG_REPO_DIR=~/repos/bigbang
```
1. Run the k3d_dev.sh script to deploy a dev cluster (-a flag required if deploying a local Keycloak):

For login.dso.mil Keycloak:
```
"${BIGBANG_REPO_DIR}/docs/assets/scripts/developer/k3d-dev.sh"
```
For local keycloak.dev.bigbang.mil Keycloak (-a deploys instance with a second public IP and metallb):
```
"${BIGBANG_REPO_DIR}/docs/assets/scripts/developer/k3d-dev.sh -a"
```
1. Export your kubeconfig:
```
export KUBECONFIG=~/.kube/<your_kubeconfig_file>
```
e.g.
```
export KUBECONFIG=~/.kube/Sam.Sarnowski-dev-config
```
1. Deploy flux to your cluster:
```
"${BIGBANG_REPO_DIR}/scripts/install_flux.sh -u ${REGISTRY_USERNAME} -p ${REGISTRY_PASSWORD}"
```

Deploy Bigbang📜

From the root of this repo, run one of the following deploy commands depending on which Keycloak you wish to reference:

For login.dso.mil Keycloak:

helm upgrade -i bigbang ${BIGBANG_REPO_DIR}/chart/ -n bigbang --create-namespace \
--set registryCredentials.username=${REGISTRY_USERNAME} --set registryCredentials.password=${REGISTRY_PASSWORD} \
-f https://repo1.dso.mil/big-bang/bigbang/-/raw/master/tests/test-values.yaml \
-f https://repo1.dso.mil/big-bang/bigbang/-/raw/master/chart/ingress-certs.yaml \
-f https://repo1.dso.mil/big-bang/bigbang/-/raw/master/docs/assets/configs/example/dev-sso-values.yaml \
-f docs/dev-overrides/minimal.yaml \
-f docs/dev-overrides/istio-testing.yaml

For local keycloak.dev.bigbang.mil Keycloak:

helm upgrade -i bigbang ${BIGBANG_REPO_DIR}/chart/ -n bigbang --create-namespace \
--set registryCredentials.username=${REGISTRY_USERNAME} --set registryCredentials.password=${REGISTRY_PASSWORD} \
-f https://repo1.dso.mil/big-bang/bigbang/-/raw/master/tests/test-values.yaml \
-f https://repo1.dso.mil/big-bang/bigbang/-/raw/master/chart/ingress-certs.yaml \
-f docs/dev-overrides/minimal.yaml \
-f docs/dev-overrides/istio-testing-local-keycloak.yaml

This will deploy the following apps for testing:

Istio, Istio operator and Authservice
Jaeger, Kiali and Monitoring (including Grafana), all with SSO enabled
Optionally Keycloak

Validation/Testing Steps📜

⚠️ For testing with a local Keycloak instance, you will need to manually register or create an account as an admin before proceeding with the below tests. For more info please reference the Keycloak DEVELOPMENT_MAINTENANCE.md.

Navigate to Jaeger (https://tracing.dev.bigbang.mil/) and validate you are prompted to login with SSO and that the login is successful. This verifies that Authservice is working as an Istio extension.
Navigate to Prometheus (also uses Authservice) and validate that the Istio targets are up (under Status -> Targets). There should be targets for istio-envoy, istio-operator and istio-pilot.
Navigate to Grafana (https://grafana.dev.bigbang.mil/) and validate that the Istio dashboards are present and show some data. You may need to alter filters to pick a workload that has information showing.
Since Kiali (https://kiali.dev.bigbang.mil/) interfaces with Istio for most of its information it is a good idea to validate its functionality. To do this, perform the test steps here.
Once you’ve confirmed that the package tests above pass, also test your branches against Big Bang per the steps in this document.

Files That Require Integration Testing📜

Some things aren’t tested by the package pipeline, but are tested by the BigBang pipeline. These need to be tested independently if updated:

Ingress Gateways
Passthrough Ingress Gateway specifically is already in BigBang, but not in the package pipeline.
Egress Gateways
./chart/templates/bigbang/istio/authorizationPolicies/allow-ingress-authz-policy.yaml
./chart/templates/bigbang/istio/authorizationPolicies/allow-nothing-policy.yaml
./chart/templates/bigbang/istio/authorizationPolicies/template.yaml
./chart/templates/bigbang/peerAuthentication.yaml

Istio Operator📜

./chart/templates/bigbang/istio-operator-rolebinding-openshift-scc.yaml
./chart/templates/bigbang/networkpolicies/additional-networkpolicies.yaml
./chart/templates/bigbang/networkpolicies/default-deny.yaml
./chart/templates/bigbang/networkpolicies/egress-kube-api.yaml
./chart/templates/bigbang/networkpolicies/ingress-scraping.yaml
./chart/templates/bigbang/openshift-cr-crb-istio-operator.yaml

Instructions for Integration Testing📜

See the Big Bang Doc