Expired or Invalid License

Symptoms

GoodData.CN needs a valid license key to run. If the key expires or the text is altered in any way, the platform stops working.

Services fail to start, or they start and then reject requests.
Any edit to the key text stops startup. That includes extra characters, stray whitespace, and line breaks.

Check

Find the Secret that holds the key. The name depends on how the platform was deployed. The Production Deployment guide creates gdcn-license and stores the key in a license entry. Older deployments may use gooddata-cn-license or a name of your own:
```
helm get values gooddata-cn -n gooddata-cn --all | grep -B1 -A3 existingSecret
```
A healthy result is a single license.existingSecret value that names the Secret your deployment reads. You can also read license.existingSecret from your values files. Whatever you find is <LICENSE_SECRET_NAME> in the commands below.
Check that the Secret exists and look for license errors in the logs. Never print the key into a shared channel:
```
kubectl get secret <LICENSE_SECRET_NAME> -n gooddata-cn
kubectl logs -n gooddata-cn deploy/<release>-metadata-api --since=15m \
  | grep -i license
```
A healthy result is the Secret listed in the namespace and no license errors in the logs. A missing Secret or a license error in the output confirms the incident.
Compare the key against what GoodData sent you. A healthy result is an exact match: every character the same, no added spaces, and the whole key on a single line.

Fix

Use this procedure for any key change: an expired key, a corrupted key, or a routine renewal. Your key already starts with key/, for example key/eyJhY2NvdW50I.... Paste it exactly as you received it, on one line, and do not add the prefix yourself.

Write the new key into the Secret. Read the key from a prompt rather than typing it into the command, so it stays out of your shell history. The apply updates the Secret if it already exists and creates it if it does not:
```
read -rsp 'GoodData.CN license key: ' GDCN_LICENSE_KEY && echo
printf '%s' "$GDCN_LICENSE_KEY" | kubectl -n gooddata-cn create secret generic <LICENSE_SECRET_NAME> \
  --from-file=license=/dev/stdin \
  --dry-run=client -o yaml | kubectl apply -f -
unset GDCN_LICENSE_KEY
```
This is the same pattern the Production Deployment guide uses to create the license Secret.
If your deployment keeps the key inline in Helm values instead of in a Secret, update license.key and run helm upgrade instead of the command above.
Restart the services so they pick up the new key:
```
kubectl rollout restart deployment -n gooddata-cn \
  -l app.kubernetes.io/name=gooddata-cn
kubectl rollout status deployment -n gooddata-cn \
  -l app.kubernetes.io/name=gooddata-cn
```
Services may pick up the updated Secret on their own, but not on a predictable schedule. Restart them rather than waiting: it takes effect immediately and costs nothing when the key was already reloaded.

Verify

Check that the pods are healthy and the license errors have stopped:

kubectl get pods -n gooddata-cn
kubectl logs -n gooddata-cn deploy/<release>-metadata-api --since=5m \
  | grep -i license

The incident is over when every pod is Running and Ready and the log grep returns no license errors. Track the expiry date of the new key and replace it before it lapses.

Escalate

If the pods still fail or the license errors continue, generate a support bundle from the affected cluster and open a case at GoodData Support, attaching the bundle plus when the problem started and what changed before it did. See Collect a Support Bundle.

Runbooks

Backup and Restore