Skip to content

Muppy 18.98.0

Preview

This page describes Muppy 18.98.0, which is not released yet. What it describes is being delivered to the customers who asked for it as the release candidate 18.98.0-rc.1, and may still change before the release.

An AI agent working through the Muppy MCP can now create the machines it needs: a container on one of your LXD hosts, or an instance in one of your OVH Public Cloud projects, each in a single call that you can gate behind your approval. What it creates is born with an environment, an AI gate it does not choose, and a date on which Muppy destroys it.

That date is the second subject of the release. Environments now end on a date: a Development or Test App Server is dated when it is created, its owner sees the days left and is reminded before the end, one dialog moves or clears the date, and a decommission never touches Production.

Around those two subjects: LXC Create checks what it runs, a guest is reached through its LXD host by default, Muppy connects only with the SSH keys it stores, and a few settings move to the screen of their feature.

Nothing to do on upgrade

The settings ship with values that change nothing you run today. Existing hosts and App Servers keep their dates, or their absence of one. The scheduled action that destroys hosts on their date, Auto-Decommission due Hosts, ships disabled: until you enable it, dates are shown and nothing is destroyed. If you enabled it before, read Development and Test App Servers are dated to see what it now applies to.

Machines created by an agent

A container in one call

create_lxc, on an LXD host, is the Create LXC wizard in one call: Muppy launches the container, registers it as a host, gives it its environment (a qualifier), its auto-decommission date and its AI gate, and enrolls it once its SSH answers. The agent gives a name, a machine type (container or virtual machine), the vCPU, RAM and disk, and the qualifier; it may pick an image of your catalog and a profile of that LXD host, and gets the host's defaults otherwise.

The list of arguments is closed. An agent gives no launch flags (Muppy computes them from the sizes), no image as free text, no port, no date and no AI gate: each of these changes what the container is or who controls it, so they stay with a person, in the wizard. A wrong name, an unknown image or a profile of another host is refused before anything is queued.

The call follows the LXD host's AI gate: on an AI Managed host it runs at once, on a closed one it becomes a permission request. The new container inherits the LXD host's AI Managed switch and nothing else — a Grant for Duration on the host is not handed down, so a container created on a host open only for a while is born closed.

The call is always asynchronous: it returns the task to follow, whose log carries the whole creation. Details and the parameter table: Creating a container.

An OVH instance in one call

create_ovh_instance, on an OVH account, is the Commission OVH Public Cloud Instance(s) wizard in one call, for one instance: Muppy creates it at OVH, registers it as a host, dates it, waits until it is active, binds its public IP, and enrolls it when asked.

Each call is a real expense

The instance is billed by OVH by the hour from its creation until it is destroyed. Its decommission date is required, in the future, and at most the Manganese Ceiling ahead (90 days by default, Settings ▸ Manganese ▸ App Server Lifetime) — for every user.

Each call creates one instance, billed hourly: no count, no monthly billing. The project, region, flavor and image are picked from the account's catalog, and a mismatch — a flavor not offered in that region, an object of another account — is refused before OVH is called. Two simultaneous calls with the same name create one instance.

The OVH account now carries an AI gate, closed by default: until you open it, each call is a permission request, and the approval screen names the project, the region, the flavor with its size, and the image. Through the MCP, the account's secret fields are never returned. Details: Creating an OVH instance.

A new OVH instance trusts the Muppy key

An instance created through the MCP receives the Muppy key, the SSH key Muppy connects with, and no other: the call takes no key. A new machine then trusts only a key whose private half never leaves Muppy, so every access to it goes through Muppy — its AI gate, its journal, its enrollment, which installs the keys your administrators declared. When the OVH project does not hold the Muppy key yet, the commission registers it there.

The commission wizard proposes the Muppy key too, and lets you choose another one, with a warning stating the rule you are setting aside. A key Muppy holds becomes the new host's control key and everything runs as usual; a key Muppy holds only the public half of cannot be reached by Muppy, so the wizard turns enrollment off and the commission stops once the instance is registered, dated and has its IP — Choosing another key.

Two failures no longer leave a half-made host: the IP bound to an instance is kept when a later step fails, and in a commission of several instances, one that fails no longer stops the others — the task reports each failed one by name at the end.

Environments that end on a date

Development and Test App Servers are dated

An App Server created under a Development or Test qualifier now gets an auto-decommission date on its host: 30 days after its creation, a horizon you set in Settings ▸ Muppy Core ▸ Auto-Decommission. Any other qualifier leaves it undated, and so does an App Server created before this release. The provisioning wizard and LXC Create show the proposed date, which you may change or empty before you launch.

What counts is the qualifier's effective category: a qualifier whose base category is Development is dated like Development, one based on Staging is not.

On that date, once Auto-Decommission due Hosts is enabled, Muppy deprovisions the App Servers of the host — their services, public URLs and DNS records, Code Server and databases — then destroys the machine: the container on its LXD host, or the OVH instance. Production is the exception, below. Changing an App Server's qualifier keeps its date, and the form says so. What a decommission destroys.

A decommission never touches Production

Whatever the date, a decommission keeps Production:

  • it deprovisions only the App Servers that are not Production; a host still carrying one is kept, machine and record, and its date is cleared;
  • a host whose own qualifier is Production is never decommissioned; if one carries a date, the Muppy Administrators get an alert;
  • a stopped container carrying a Production App Server is never started to be decommissioned: nothing is done, the date stays, and the administrators get an alert listing the host, each App Server with its qualifier and what would happen to it, and the two ways out — start the container yourself, or clear the date;
  • creating an App Server or a container refuses a date on a Production qualifier.

A decommission also refuses a host that others still need: one running containers or virtual machines, or one serving a PostgreSQL cluster or a Traefik server to App Servers elsewhere. The Hosts Pending Deprovision tile shows each host's qualifier. Production.

One dialog to move the date

Manage Decommission replaces the Schedule, Extend and Clear buttons. It opens from the Host form and from the App Server form, and offers Schedule, Extend, Set Date and Clear; Decommission Now stays beside it. The host records who last changed its date, and when.

A Manganese user manages the date of the host of their own App Servers, up to the Manganese Ceiling after the host's creation (90 days by default), and clears it only when Allow MGX users to clear is on — off by default. Both live in Settings ▸ Manganese ▸ App Server Lifetime. A Muppy user is bound by neither. App Server Lifetime.

Days Left, and two reminders

A Days Left capsule shows on the Host and App Server forms and in their lists — "12 days", "7 h", "Due" — green, then orange from the first reminder, then red.

Two emails warn before the date, 7 days and 1 day ahead by default (Settings ▸ Muppy Core ▸ Auto-Decommission): to the owner of each App Server on the host, or to the person who created a host carrying none. Moving the date re-arms them. None is sent while Auto-Decommission due Hosts is disabled, since nothing is destroyed then, and none goes to the owner of a Production App Server. Days Left · Reminders.

LXC containers

LXC Create checks what it runs

Every container creation — the wizard, the MCP call, the provisioning of an App Server — now runs on the LXD host only arguments Muppy has checked: the name is validated in full, and every value reaches LXD as one argument, whatever it contains.

An image given as text must come from a remote listed in Allowed LXC Image Remotes (Settings ▸ Muppy LXD ▸ Images), which allows ubuntu by default; an image of your catalog is always accepted. Which images are accepted.

Deleting a container whose deletion LXD refuses now keeps its host record, instead of forgetting a container that still runs.

A guest is reached through its LXD host

A new guest is reached over SSH through its LXD host as a jump host, unless its LXD host's pool asks for a dedicated port. A bridged guest and a virtual machine never get a port of their own. The Create SSH Proxy box of LXC Create follows that rule by default. An existing guest keeps the access it has. Reaching the new guest.

The LXC settings have their own screen

The six LXC settings move to a settings app of their own, Muppy LXD, in three blocks: LXD, Images and Image Store. Their values do not change, and every message that names one gives its path.

SSH connections

Muppy connects only with the SSH keys it stores. It no longer falls back on a key file of the server it runs on, or on an SSH agent: a host Muppy reaches, it reaches for a reason you can see in Muppy. A refused key now says Authentication failed, where it used to surface as an unrelated parse error.

A failed connection is closed at once, with the jump host it went through. A host that refused Muppy's key no longer accumulates half-open connections until its SSH server turns everyone away. Waiting for a host to restart stops after ten refusals of the key, naming the host and the key offered.

Overwriting a host's authorized keys is refused unless the new list keeps the key Muppy connects to that host with — its own control key when it has one, the Muppy key otherwise — so that the overwrite cannot lock Muppy out.

Settings and forms

  • Manganese Ceiling (days) moves to Settings ▸ Manganese ▸ App Server Lifetime, beside Allow MGX users to clear. Its help says it also bounds the date of an OVH instance created through the MCP.
  • Default LXC Allocator becomes Application default LXC Allocator, in Settings ▸ Muppy ▸ Applications: it is read only when an App Server is provisioned, and its help says what changing it costs.
  • The OVH account form is reorganised: Connect and Disconnect in the header, the error as an alert, the catalog selection in its own group, the dangerous buttons marked as such.
  • No label wraps on the forms this release touches — Host, App Server, the OVH account, the commission and provisioning wizards, LXC Create, Manage Decommission — and their alerts keep their margins.