You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During migrations of environments from one target to another, the old namespace remains in the old target after migrations are performed, and could be forgotten about.
It could be useful to scan namespaces for a label like lagoon.sh/expiration=${timestamp} and then perform a deletion of that namespace.
The text was updated successfully, but these errors were encountered:
lagoon.sh/forceExpire=true could delete the namespace as soon as the next cleanup job runs
lagoon.sh/expiration=${timestamp} could delete the namespace on the next cleanup after this expiration date
We could also have configurable warning message too for a period in advance of the expiration date to say that the namespace will be removed.
In some cases development environments could be removed after a defined period too, and the expiration could be incremented after each deployment to ensure it remains active for a period of time.
Since Lagoon namespace tokens can't label the namespace, but a task in Lagoon that performs migrations may need a way to mark an old namespace as ready for removal, there needs to be a way to mark a namespace as expired via something like a kind: Secret or kind: Configmap that contains the expiration timestamp.
During migrations of environments from one target to another, the old namespace remains in the old target after migrations are performed, and could be forgotten about.
It could be useful to scan namespaces for a label like
lagoon.sh/expiration=${timestamp}
and then perform a deletion of that namespace.The text was updated successfully, but these errors were encountered: