Day-2 operations

Terraform

Each installer tag matches one chart version, so move your installer clone to the tag for the new version first. Use the newest v<chart_version>-r<n> tag when one exists. Your terraform.tfvars, override files and state stay in place.

git fetch --tags
git checkout v<chart_version>

Set chart_version in your terraform.tfvars (or TF_VAR_chart_version) to the same version.

Next, settle every new setting before Terraform sees the new defaults. The installer’s capabilities.yaml lists each capability and changed default, with the installer version that introduced it. For every entry newer than the version you run, decide enable, disable or keep what I have, and write the answer into terraform.tfvars (the entry’s enable and disable lines are the exact text). An explicit value means a later default never moves under you. Entries marked disruptive: true deserve the most care:

• Node sizes. If you never set them, a new default size replaces the spaces node group and stops every running space. Pin your current values to keep the group as it is (on EKS node_instance_types and node_disk_size_gb, on GKE the machine_type and disk_size_gb of each spaces_pools entry). Move to a new size later by adding a second group. See Sizing.

• Platform pool and bundled datastores. When this upgrade turns taint_control_plane_pool on (an install from 0.29 or older, or one that set it to false) and you run the bundled Redis or Postgres, set pin_bundled_datastores = false with it, so the datastores keep their volumes where they are while the platform pods move. Check where they run first:

  kubectl get pod -n marshal marshal-redis-master-0 marshal-postgresql-0 -o wide
  kubectl get nodes -l workload=control-plane

  If they already run on a control-plane node, keep the default true. With false they stay where they are until they are next rescheduled, which then needs a node outside the control-plane pool in their volume’s zone.

The install-marshal skill in the installer walks you through these questions one at a time. Then download the providers the new tag needs, and read the plan before you apply:

terraform init -upgrade
terraform plan
terraform apply

The plan should show no replacement you did not choose: a node group or node pool marked must be replaced means a size is not pinned yet. Terraform then pulls the new chart and runs helm upgrade in place, with the installer built for that version.

ArgoCD

Set targetRevision in application.yaml to the new chart version, commit it, then sync:

argocd app sync marshal

With syncPolicy.automated, the sync starts by itself once the commit lands.

Terraform

A Terraform install goes through Helm, so roll back with Helm:

helm rollback marshal -n marshal

Then set chart_version back to the previous value in your tfvars, so the next terraform apply keeps you there.

ArgoCD

Revert the commit that changed targetRevision, then sync:

git revert <commit>
argocd app sync marshal

You can also roll back in ArgoCD directly with argocd app rollback marshal. With selfHeal on, use the revert: ArgoCD reapplies whatever git says on its next reconcile.

Terraform

Set installation_jwt in your terraform.tfvars (or the environment variable), then run:

terraform apply

ArgoCD

Update the license Secret in place, and restart the API so it reads the new value:

kubectl create secret generic marshal-license -n marshal \
  --from-literal=jwt="<new-jwt>" \
  --dry-run=client -o yaml | kubectl apply -f -
 
kubectl rollout restart deployment/marshal-api -n marshal

The Application does not change. ArgoCD only references the license Secret and never manages it.