Changes to the "config-network" ConfigMap for enabling Auto TLS gets rolled back by kapp
Article ID: 297871
Updated On:
Products
Issue/Introduction
This problem can occur when updates are made to the ConfigMap named config-network under knative-serving namespace. Because of the current kapp configuration, the changes will be reverted back shortly (~30 secs) to its original state.
This is a known issue.
Product: VMware Tanzu Application Platform
Component: Cloud Native Runtimes
Affected versions: TAP v1.0.x/CNR v1.1.0 or below
Fixed Versions: CNR v1.1.1 and above
Environment
Resolution
The instructions below shows multiple ways to apply a ytt overlay to a CNR deployment based on the installation scenario.
Scenario #1: User deployed CNR through TAP profiles
Summary:
As of TAP 1.0, there is a Top Level Key called package_overlays in the yaml configuration for TAP (tap-values.yaml) that can be used to modify an existing PackageInstall.
Workaround steps:
1. Create a yaml file with a ytt overlay to patch CNR.
$ cat <<EOF > cnrs-overlay-config-network.yaml
#@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.subset({"kind":"ConfigMap","metadata":{"name":"config-network","namespace":"knative-serving"}})
---
data:
#@overlay/match missing_ok=True
auto-tls: Enabled
EOF
2. Create a secret in the tap-install namespace. The secret contains the overlay created in the previous step.
$ kubectl -n tap-install create secret generic cnrs-overlay-config-network \ -o yaml \ --from-file=cnrs-overlay-config-network.yaml
3. Append the snippet below to the end of the tap-values.yaml file which was used to deploy TAP/CNR.
$ cat <<EOF >> tap-values.yaml package_overlays: - name: cnrs secrets: - name: cnrs-overlay-config-network EOF
4. Update the TAP installation with the changes.
$ tanzu package installed update tap -n tap-install -v 1.0.0 -f tap-values.yaml
5. Confirm TAP PackageInstall changes have been reconciled successfully.
$ tanzu package installed get tap -n tap-install
6. Confirm the changes were applied by verifying config-network ConfigMap.
$ kubectl get configmap config-network --namespace knative-serving --output jsonpath="{.data.auto-tls}"
Scenario #2: User deployed CNR through TAP but installed it individually (by not using tap-values.yaml)
Summary:
An annotation is applied behind the scenes to CNR's PackageInstall because of the presence of package_overlays key defined inside tap-values.yaml. This annotation points to a kubernetes secret which contains the contents from the overlay. Since in this scenario, the user doesn't have access to the package_overlays field, we will simulate the process by creating a secret and annotating the CNR PackageInstall manually.
Workaround steps:
1. Create a yaml file with a ytt overlay to patch CNR:
$ cat <<EOF > cnrs-overlay-config-network.yaml
#@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.subset({"kind":"ConfigMap","metadata":{"name":"config-network","namespace":"knative-serving"}})
---
data:
#@overlay/match missing_ok=True
auto-tls: Enabled
EOF
2. Create a secret in the tap-install namespace. The secret contains the overlay created in the previous step.
$ kubectl -n tap-install create secret generic cnrs-overlay-config-network \ -o yaml \ --from-file=cnrs-overlay-config-network.yaml
3. Add the annotation below to the CNR's PackageInstall which contains the secret name created above.
$ kubectl annotate packageinstall cnrs "ext.packaging.carvel.dev/ytt-paths-from-secret-name.0"="cnrs-overlay-config-network" -n tap-install
4. Confirm the annotation was added successfully.
$ kubectl get packageinstall cnrs -n tap-install -ojsonpath="{.metadata.annotations.ext.packaging.carvel.dev/ytt-paths-from-secret-name.0}" | grep overlay
5. Confirm the changes performed by the overlay were applied. In this example, that means looking at the config-network ConfigMap.
$ kubectl get configmap config-network --namespace knative-serving --output jsonpath="{.data.auto-tls}"
Feedback
