Move application between namespaces

Disclaimer

Although the switch between the new and old application expected to be almost instantaneous, we cannot guarantee that no requests will fail during the switchover.

Steps

Create secret object for the application in the new namespace.

gap-cli config:init -n <your-namespace> --app <your-application-name>

Copy the app’s secret object ON BOTH clusters from the old namespace to the new namespace. Note that after finishing the migration process, all the secrets need to be rotated for security reasons.
Either put the person who is migrating the application to both team’s g-gsuite group in GSuite admin (can be done by the admins, for example the tech lead) or the tech lead can migrate the secret.
Edit the gap.yaml to use the new namespace.
You need to add the migration: "true" label to your ingress. (true is a string in this case, so quotes are needed!)
If you are using a custom ingress simply add this label to your ingress:
```
...
metadata:
  labels:
    migration: "true"
```
If you are using an autogenerated ingress, you need add it as a label in your gap.yaml:
```
...
deployments:
  example-deployment:
    ingress:
      enabled: true
      labels:
        migration: "true"
```
Make sure that you’ve changed all the namespace references in the Kubernetes yaml files in your code to recreate all the resources related to a namespace.
If the application changes area, in the CI config, update the deployer username and the users key json to the new area’s deploy user.
Deploy your application. At this point the traffic will stay on the application in the old namespace.

If you’re using Workload Identity don’t forget to bind the Kubernetes Service account in the new namespace to the existing GCP service account with the corresponding GCP command.

Delete everything related to the application in the old namespace by running the following commands:

# if the application is exposed outside of GAP via Ingress, delete the Ingress object in the old namespace:
kubectl delete ingress <your-application-ingress-name> -n <your-namespace>
# if the application is onboarded to Service Mesh, delete the VirtualService in the old namespace:
kubectl delete virtualservice <your-application-name>--web -n <your-namespace>
# at this point your new deployment will receive the traffic, you should validate that it works as expected, then continue

# this command will delete only specific resources
kubectl delete all -n <your-namespace> -l applicationName=<your-application-name>

# additional resources to delete
kubectl delete secret -n <your-namespace> <your-application-name> <your-application-name>-backup <your-application-name>-<your-web-deployment-name>-tls
kubectl delete serviceaccount -n <your-namespace> <your-application-name>-<staging | production>
kubectl delete poddisruptionbudget -n <your-namespace> -l applicationName=<your-application-name>

If you’d like to make sure that do you did a total clean-up, feel free to run the following command to browse through all the namespace related resources then delete them one by one:

kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --ignore-not-found --show-kind -n <your-namespace>

Sync your app to production
Redo the above deletion steps in production before removing the patch or the label from gap.yaml
Delete the patch or the label from your custom ingress from the repository. This is very important, because the label makes the ingress object to skip validation before entering the cluster and a misconfiguration can severly affect access to all services in the cluster.
If someone’s permission was changed in the first steps, revoke these changes.
If there are any specific alerts to the application in the alerts repo, transfer them to the new team’s folder, and edit the namespace in the definitions.
Same as above for any elastalerts.
If the application has attached resource projects (for CloudSQL for example), give Owner role to the new team’s g-gsuite-teamname@emarsys.com group. Also remove the old team’s group’s owner role.
After you migrated both staging and production environments to the new namespace reconnect your application’s logging in Laas Configurator.
Open you application’s page in [ArgoCD][argo-cd] and delete it with Foreground propagation policy, so your application will show Missing status.
Open a ticket requesting the deletion of the ArgoCD entries for your old namespace:

Dear Cloud Platform team,

please remove the following application(s) from the gap-applications repository:
- <argo-app-name-1>
- <argo-app-name-2>

Cheers,
<your-name>