Why Changes Made in the Cloud Console or with kubectl Are Reverted

If you changed something directly in the AWS or GCP console, or with
kubectl edit, and it went back to how it was, this page explains why that
happens, which changes belong in SVIEW, and how to make a temporary change that
sticks for as long as you need it.

Why your change went back

Everything the platform creates for you is declared in SVIEW as desired
configuration. The platform keeps comparing what is actually running against
that configuration, and puts back anything that differs:

• Kubernetes objects (Deployments, Services, ingress routes, ConfigMaps) are
  deployed through GitOps with ArgoCD, which corrects differences
  automatically. A kubectl edit, kubectl scale or kubectl patch on a
  platform-managed object is usually undone within minutes.
• Cloud resources (databases, node pools, buckets, IAM roles, security
  rules) are provisioned as infrastructure as code with Terraform. A console
  edit to one of these is put back the next time that resource is reconciled,
  which may not happen straight away — so a console change can look as if it
  worked, then disappear later.

This is deliberate. It is what keeps every Environment reproducible, keeps the
Versions history in SVIEW accurate, and lets a failed node or a rebuilt
cluster come back exactly as configured.

flowchart LR
    S["SVIEW configuration<br/>(desired state)"] --> P["Platform applies it"]
    P --> L["Running resources"]
    C["Console or kubectl edit"] -. "creates a difference" .-> L
    L -- "difference detected" --> P

A console change that has not been reverted yet is not safe either. It can
still be overwritten at the next reconciliation, or the next time anyone saves
that Component in SVIEW. Treat any change made outside SVIEW as temporary and
unrecorded.

What to change in SVIEW

A change saved in SVIEW is recorded in the Component's Versions tab, so you
can see who changed what and roll it back later. See
Configuration Versions and Rollback.

What is safe to do outside SVIEW

Read-only work in the cloud console or with kubectl does not change the
desired state, so nothing is reverted:

• Looking at resources, their settings, metrics and monitoring graphs
• Reading logs, events and pod status — see
  Namespace Access
• Restarting a workload or deleting a single pod so it is recreated. This does
  not change its configuration — see
  Restart an Application or a Single Pod

Console access comes through an approved, time-limited access role — see
Temporary AWS Console Access Through Teleport.
If a change you need is refused there, that is expected: make it in SVIEW, or
raise a request.

Making a temporary capacity change

A common case is sizing up a database or an application for a load test, a
migration or a busy period, then sizing it back down. Do both halves in SVIEW:

1. Open the Component in SVIEW and edit its configuration.
   • For an application, raise the replica count or the CPU and memory
     requests and limits.
   • For a database, raise the instance size. On AWS RDS and GCP Cloud SQL
     this is the master_instance_type value, for example db.r5.large on
     AWS or db-custom-1-3840 on GCP.
2. Click Save and wait for the Component to show as healthy again.
3. When you no longer need the extra capacity, open the Component again and set
   the value back, or roll back to the earlier version from the Versions
   tab.
4. Click Save.

If your SVIEW role cannot edit the Component, raise a request in your dedicated
Slack channel with the Environment, the Component name, the new size and how
long you need it. We make the change in SVIEW for you, and change it back when
you tell us.

If a console change was already made

Put the same change into SVIEW. Once SVIEW holds the value you want, the
platform keeps it instead of reverting it. If you are not sure what was changed
outside SVIEW, or it is not something you can set in SVIEW, raise a request in
your dedicated Slack channel with the Environment, the resource name and what
was changed.

Related articles

• What You Can Do vs. What We Manage — what is self-service and what needs a request
• Components and Deployments — changing a Component's configuration
• Configuration Versions and Rollback — undoing a change you made in SVIEW
• Data Services — database and cache Components
• Restart an Application or a Single Pod — a safe kubectl action
• The Boundary in Detail — the same boundary with the technologies named