Skip to main content

How-To: Update Application Values in Your -deploy Repository

Introduction​

This guide shows you how to change your application's runtime configuration — environment variables, replica counts, and especially resource requests and limits — by editing the values files in the -deploy repository you own.

Every application deployed to W.W. Norton's EKS clusters is configured through one values.yaml file per environment, stored in your -deploy repository. FluxCD watches that repository and applies your changes automatically: you never run helm or kubectl to update configuration — you merge a change to a values file and Flux does the rest.

Prerequisites​

Before you start, make sure you have:

  • Developer or Maintainer access to your application's -deploy repository in W.W. Norton's GitLab organization
  • Knowledge of which environments your application runs in (dev, qa, stg, prod)
  • A reviewer available to approve your Merge Request

Where values live​

Your -deploy repository contains one directory per environment under flux/:

<application-name>-deploy/
└── flux/
    ├── dev/
    │   └── values.yaml    # Development environment values
    ├── qa/
    │   └── values.yaml    # QA environment values
    ├── stg/
    │   └── values.yaml    # Staging environment values
    └── prod/
        └── values.yaml    # Production environment values

Each cluster reads only its own file. Changing flux/dev/values.yaml affects the dev cluster and nothing else.

Why doesn't my repository have a chart/ folder?

Some -deploy repositories are part of the new Unified Chart standard: the Helm chart is maintained centrally by the platform team, so the repository no longer needs its own chart/ directory (you may see it removed, or renamed to chart.disabled). Older repositories still carry a per-app chart under chart/.

This does not change anything in this guide. In both cases your configuration lives in flux/<environment>/values.yaml, and the steps below are identical. See the Developer deployment guide for Unified Chart if you want to learn more about the standard.

How to update your application's values​

Step 1: Create a feature branch​

Clone your -deploy repository and create a branch. The main branch is protected, so all changes go through a Merge Request.

git clone git@gitlab.com:wwnorton/<group>/<application-name>-deploy.git
cd <application-name>-deploy
git checkout -b feature/<short-description>

Step 2: Edit the values file for the target environment​

Open flux/<environment>/values.yaml for the environment you want to change — and only that one. Common changes:

Environment variables:

app:
  envvars:
    - name: MY_FEATURE_FLAG
      value: "true"

Resource requests and limits:

resources:
  requests:
    cpu: 250m
    memory: 512Mi
  limits:
    cpu: "1"
    memory: 2Gi

Keep the change minimal and do not reformat the rest of the file — smaller diffs make reviews faster and rollbacks safer.

If your repository uses the Unified Chart, you can validate your values file against the chart's schema before opening the Merge Request:

cd <PATH_TO_UNIFIED_CHART_DIRECTORY>
helm lint ./chart -f <PATH_TO_YOUR_VALUES_FILE>

Step 3: Open a Merge Request and merge it​

Push your branch and open a Merge Request against the branch Flux tracks — usually main.

git add flux/<environment>/values.yaml
git commit -m "Increase memory limits for <environment>"
git push -u origin feature/<short-description>

Once approved and merged, your part is done.

If you are unsure which branch Flux tracks for your application, check the ref: field of your application's GitRepository resource in the cluster-manager repository under clusters/tf-<environment>-cluster/flux-config/, or ask the Platform Team.

Step 4: Wait for Flux to apply the change​

Flux syncs your repository every minute. After the merge:

  • Per-app chart repositories: the HelmRelease detects the new commit and upgrades the release directly.
  • Unified Chart repositories: Flux first regenerates your application's values ConfigMap, then the HelmRelease picks up the new values and upgrades the release.

Either way, expect the new configuration to start rolling out within one to two minutes of the merge.

Step 5: Verify the rollout​

Confirm the change reached the cluster:

kubectl -n <application-namespace> rollout status deployment/<application-name>
kubectl -n <application-namespace> describe deployment <application-name>

You can also watch your application's dashboard in Grafana — see Grafana Pod Level Info Dashboard.

Overriding namespace LimitRanges with resource requests and limits​

Every namespace has a LimitRange that applies default resource requests and limits to any container that does not declare its own. To override those defaults, declare an explicit resources: block in your values file (as shown in Step 2) — an explicit value always takes precedence over the LimitRange defaults.

The default, minimum, and maximum values for each namespace and environment are maintained by the platform team in the cluster-manager repository — see the LimitRange values reference for the tier defaults and the per-namespace overrides. You can also check the live values applied to your namespace at any time:

kubectl -n <application-namespace> describe limitrange

LimitRange maximums cannot be overridden from values. The namespace LimitRange also enforces max (and min) constraints at admission time. If your resources.limits exceed the namespace maximum, Kubernetes rejects the new pods after the merge: the HelmRelease can look healthy while the rollout silently stalls. The rejection only shows up in the ReplicaSet events:

kubectl -n <application-namespace> describe replicaset -l app.kubernetes.io/name=<application-name>

Look for forbidden: maximum ... usage per Container is ... messages.

If your application genuinely needs more than the namespace ceiling, the LimitRange itself must be changed — it is managed by the platform team in the cluster-manager repository. Reach out to the Platform Team with the namespace, the environment, and the resources you need.

Troubleshooting​

  • Change merged but nothing happened: confirm you edited the values file for the right environment, and that you merged into the branch Flux tracks (see Step 3).
  • Rollout stalls with no visible error: check the ReplicaSet events for LimitRange rejections (see the warning above).

For additional support or questions, please reach out to the Platform Team