Decommissioning of an app

[lvbachmann]

Introduction

We now allow the app owner to deploy the app, but there's no way to "undeploy" it. This functionality should be available.

In scope

• Stopping the app
  • Technically - how do we do this?
  • Functionality available in Studio
  • Who gets rights to do this? Follow deploy rights or separate group?
  • Design for this?
• Page for handling active instances of a decommissioned app - what do we show the user?
  • Updating all instances? A status? Property "decommissioned"?
  • Filter out these instances from the message box entirely? Or a standardized page? --> Filter!
• Dedicated end point for decommissioning in Storage

Out of scope / additional ideas

1. ValidFrom and ValidTo should be environment specific? The validity date of an app might be different from one environment to the other. The two dates are currently defined on the application metadata document under config of the app. This is probably fine for most cases, but it should probably be possible to set the dates as a part of deploy instead of as a part of development.
2. Make the App respect it's own validity dates. A running App does not use the ValidFrom or ValidTo dates for anything today. The idea here is to make the App respect it's own start and end dates. It should display an informational message if the ValidFrom date is in the future and a similar message if someone is trying to create a new instance on an app that has a ValidTo date i the past.
3. Automatic detection of an unused AKS cluster. Automatic alert for when all apps in the AKS cluster for an application owner have been decommissioned.

Product requirement

App decommissioning

1. User is given a warning. Especially so if the existing ValidTo date is set in the future.
   • This logic will need to retrieve the current application metadata from the environment. Using the application metadata stored in the local git repo might be wrong.
   • User will need the deploy rights (be member of the deploy group for the environment.)
2. Invalidating the app by setting a new field deactivated/decommissioned(Date) property of the application metadata.
   • The updated metadata document is then uploaded to platform.
3. Stopping any running pods.
4. Removing deployments (delete helm and AKS resources).
5. Delete the APIM Subscription Key.
   • It is possible to disable a subscription key, but that would require new logic to enable it again if the app is redeployed. It's easier to simply create a new key.
6. More cleanup?
7. Updating an Audit log that records who and when the decommission was triggered.

It should be possible to create an Azure DevOps pipeline that can run the necessary commands and scripts to remove an app from the AKS cluster of the application owner. Point 3-6 above. Pipelines are already responsible for building and deploying the app.

Existing active instances

It will become impossible to complete the process of active instances. The suggestion is to simply hide them.

Storage can be updated to filter out instances of apps that are inactive. Endpoints that work on a single instance should start returning 404.

An old URL pointing to an instance of a decommissioned app will probably receive a 404 in response. The response would be generated by Treafik as it wouldn't find a rule for the given URL.

Design requirement

• A new button or clickable feature on the deployment dashboard that starts the "wizard". One button for each environment? Pop-up or pop-in?
• Once the process is started there needs to be a warning of the seriousness of the action. A suggestion here is to display the ValidTo date of the app. If the ValidTo date is in the future a warning should point this out. "Remember that it is possible to deploy a new version of an app without decommissioning in between".
• A check box of type "I understand what I'm doing" ?
• A new button starts the actual decommissioning.
• The audit log will be updated with an entry for who and when the app was decommissioned. This should probably be visible somewhere on the dashboard. This could be a part of the existing list of deployments with some minor changes. There should be good visible difference between a deployment and a decommissioning.

Technical/Engineering requirement

• A new Azure DevOps pipeline performing the actual removal of an app from an environment
• Updated Audit log for an app to be displayed by deployment dashboard.
• Call to Storage to retrieve the app metadata for the specific environment.
• Call to Storage that will set the deactivated date for the app to current UTC time.

Open questions

1. It is suggested that decommissioning is to simply be a new entry in the deployment log. Maybe decommissioning should be a separate indicator?
2. Designer use the existing Update Application endpoint in Storage, instead of giving Storage a new endpoint.

### Tasks
- [ ] #6104
- [ ] #6079
- [ ] #6082
- [ ] #6064
- [ ] #6076
- [ ] #6095
- [ ] #5870
- [ ] https://github.com/Altinn/altinn-storage/issues/30
- [ ] https://github.com/Altinn/altinn-studio/issues/10758

[lvbachmann]

Grace period between decommissioning ordered and it actually happening?

[nkylstad]

Closing this issuse as outdated. https://github.com/Altinn/altinn-studio/issues/13303 will take over.