App Server Lifetime¶
An App Server created for development or test has an end date. The machine it runs on — its container, or its cloud instance — carries an Auto-Decommission Date: on that date Muppy destroys the machine and everything on it. This page explains what the date means, where it comes from, and how to move it.
What is destroyed on that date¶
The date belongs to the host of the App Server, not to the App Server itself. Several App Servers running on one host share its date.
When the date has passed, Muppy decommissions the host in three steps. When an App Server is to be deprovisioned, a stopped container is started first: the deprovisioning works over SSH. A stopped container that also carries a Production App Server is never started, since the Production App Server would start with it: nothing is deprovisioned, the host keeps its date, and the Muppy Administrators are alerted to start it themselves, then decommission it again, or to clear the date.
- Each App Server on the host, except the Production ones, goes through Deprovision Server with five of its six options checked: Remove Systemd Units, Remove Reverse Proxy Apps (its Traefik applications and their DNS records), Remove Code Server (unchecked when a kept Production App Server shares that Code Server), Remove Database (its databases and PostgreSQL roles) and Delete Dev Server object. Deprovision Server stays unchecked: the machine is destroyed once, in the next step.
- The machine is destroyed — the container on its LXD host, or the OVH instance — unless a Production App Server remains on it. The host is then kept, with its machine, and its date is cleared.
- The host record is deleted.
The auto-decommission sweep runs every hour once your Muppy administrator has enabled it.
A decommission cannot be undone
The databases and the DNS records of every App Server deprovisioned, and the files of a destroyed machine, are gone with it. Back up first anything you want to keep.
Production App Servers¶
A Production App Server — one whose Qualifier has Production as its effective category: the category it is based on, or its own when it is based on none — is never deprovisioned by a decommission: nothing of it is touched, and its owner gets no reminder. On the date, the other App Servers of its host are deprovisioned all the same; the host and its machine are kept while a Production App Server remains on it, and the host's date is cleared, so its Days Left capsule disappears.
A host whose own Qualifier is Production is never decommissioned: it shows no Days Left capsule, and Manage Decommission refuses to date it.
The default date¶
An App Server's host gets its date at creation, from the App Server's Qualifier:
| Qualifier category | Default Auto-Decommission Date |
|---|---|
| Development, Test | The creation date plus the default horizon — 30 days unless your administrator changes it |
| Any other (Staging, Demonstration, Production, …) | None: the host is kept until someone dates it |
The category read is the Qualifier's effective one: a Qualifier based on Test counts as Test.
A Production App Server takes no date: the Create App Server form hides the date for a
Production Qualifier, and a date given with one — through mgx_create_app_server, for
instance — is refused before anything is created.
The date is decided once, at creation. Changing the App Server's Qualifier afterwards does not change it: an App Server moved from Development to Production keeps its date, and one moved into Development gets none. The App Server form warns about it when the Qualifier changes, with the date that stays; only Manage Decommission changes it. Moved to Production, the App Server is told what the date does then: it is never deprovisioned by it; on that date the host's other App Servers are deprovisioned, and the host is kept while a Production App Server remains on it.
Days Left¶
An App Server whose host carries a date shows a Days Left capsule, under its Qualifier on the form and as a column in the App Server lists. It counts the time left before the date:
| Shows | When |
|---|---|
12 days |
More than 24 hours left, rounded up |
7 h |
The last 24 hours, rounded up |
< 1 h |
Less than an hour left |
Due |
The date is reached: the next pass of the sweep destroys the host |
Its colour follows the two reminders below:
| Colour | When |
|---|---|
| Green | Before the first reminder — more than 7 days left by default |
| Orange | Between the two reminders — 7 days or less, by default |
| Red | After the last reminder — 1 day or less by default — and once the date is reached |
An App Server whose host has no date shows no capsule.
Reminders¶
Muppy emails two reminders before the date: the first 7 days before it, the last 1 day before it, unless your administrator changes these delays. Muppy checks every hour for the reminders that are due, so each one goes within the hour its delay is reached. Each one goes once; when the date changes — extended, or chosen again — both go again for the new date. A host dated less than a day ahead gets only the last one.
Each App Server on the host, except the Production ones, sends its own email, to the App Server's Owner. The email names the App Server and says:
- the date, in the owner's timezone, and the time left;
- what is destroyed on that date: the App Server and its databases, its Traefik applications and their DNS records, and the host with every App Server it carries. When a Production App Server remains on the host, the email lists what the deprovisioning of this App Server destroys — its databases, its Traefik applications and their DNS records, its systemd services and its Code Server, unless a Production App Server shares that Code Server — and says that the host and its machine are kept;
- how to keep it longer: open the App Server and click Manage Decommission. When the date has reached the ceiling, the email asks you to turn to your Manganese admin or your Muppy administrator instead;
- a link to the App Server.
An App Server with no owner, or whose owner has no email address, gets no email; neither does a Production App Server. The reminders go only while the auto-decommission sweep is enabled: without it, nothing is destroyed on the date. A sweep that an administrator runs in dry run, logging the due hosts without destroying them, counts as enabled: the reminders still go.
Seeing and moving the date¶
The Manage Decommission button, in the header of the App Server form, opens a dialog on the App Server's host. It shows:
- the current Auto-Decommission Date (empty when the host has none);
- the Latest Date Allowed, for a Manganese user — see The ceiling;
- who last changed the date in this dialog, and when.
It offers the gestures your role allows:
| Gesture | What it does |
|---|---|
| Schedule | Offered when the host has no date: dates it the default horizon from now |
| Extend | Pushes the date by the default horizon, from the current date — or from now when the current date has passed |
| Set Date | Gives the host the New Date you choose, which must be in the future |
| Clear | Removes the date: the host is kept until someone dates it again |
After each gesture the dialog shows the new date and what happened. The host records your name and the time of the change.
The ceiling¶
A Manganese user cannot date a host later than its creation date plus the ceiling, 90 days unless your administrator changes it (Settings ▸ Manganese ▸ App Server Lifetime ▸ Manganese Ceiling (days)). The dialog shows that limit as Latest Date Allowed:
- a date you choose beyond it is brought back to it, and the dialog says so;
- Extend is no longer offered once the date has reached it.
To keep an environment beyond the ceiling, ask a Muppy administrator: a Muppy user is not bound by it.
Who can change the date¶
A decommission deprovisions the App Servers on the host, so changing its date requires access to every one of them, the Production ones included.
| Role | Can change the date of | Ceiling | Clear |
|---|---|---|---|
| Manganese user | the host of their App Server, when every App Server on that host is theirs | Yes | Only when Allow MGX users to clear is on |
| Manganese admin | the host of any App Server of their company, when every App Server on that host belongs to it | Yes | Only when Allow MGX users to clear is on |
| Muppy user | any host Muppy may decommission | No | Yes |
A Manganese user whose App Server shares its host with a colleague's sees the dialog without its gestures, and a message sending them to their Manganese admin. The same holds, for a Manganese admin too, on a host that runs containers or VMs of its own: destroying it would destroy them.
Allow MGX users to clear is off by default: a Manganese user moves the date, never removes it. An administrator turns it on in Settings ▸ Manganese ▸ App Server Lifetime.
Settings¶
| Setting | Where | Default |
|---|---|---|
| Default horizon — the step of Schedule and Extend, and the default date of a Development or Test App Server | Settings ▸ Muppy Core ▸ Auto-Decommission ▸ Default Horizon (days) | 30 days |
| Ceiling — the latest date a Manganese user can give a host, after its creation | Settings ▸ Manganese ▸ App Server Lifetime ▸ Manganese Ceiling (days) | 90 days |
| First reminder, and the end of the green capsule | Settings ▸ Muppy Core ▸ Auto-Decommission ▸ First Reminder (days before) | 7 days |
| Last reminder, and the start of the red capsule | Settings ▸ Muppy Core ▸ Auto-Decommission ▸ Last Reminder (days before) | 1 day |
| Whether a Manganese user can clear the date | Settings ▸ Manganese ▸ App Server Lifetime ▸ Allow MGX users to clear | Off |
On the Muppy side¶
The date applies only to the hosts Muppy may destroy: the containers and VMs it created on an LXD host, and the cloud instances it owns, never a host whose own Qualifier is Production. On any other host the dialog says that a date would have no effect. Muppy users also reach the dialog from the Lifecycle tab of the Host form, next to Decommission Now, and see the Days Left capsule on hosts too. A container that carries no App Server reminds the user who created it. The sweep, the dashboard tile and the Host form are described in Hosts › Auto-decommission.