Server Types¶

A Server Type (mpy.server_type) parameterizes how a Host is enrolled and lets you apply provider- or setup-specific behavior. Every Host references one Server Type, and the enrollment sequence reads its flags to decide which steps to run.

Server Types are managed from Muppy ▸ Configuration ▸ Server Types.

Enrollment toggles¶

The following boolean flags drive the enrollment sequence. Each one enables or skips the corresponding step:

Flag	Label	Effect when enabled
`do_update_upgrade`	Launch OS update / upgrade	Runs `apt update` / `upgrade` / `autoremove`.
`do_install_muppy_required_packages`	Install Muppy required packages	Installs the packages Muppy needs (`daemontools`, `software-properties-common`, `htop`, `iotop`, `fio`, `python3-*`, `jq`).
`do_activate_ufw`	Activate UFW Firewall	Enables the UFW firewall (still gated by the global setting and the Host's "Don't activate FW at Enroll" flag).
`do_collect_all_facts`	Collect Facts	Launches a full Facts collection.
`do_add_default_keys`	Add Default SSH Keys	Pushes the default SSH keys to the control user.
`do_reboot`	Reboot Host	Reboots the Host at the end of enrollment.

In addition:

Wait for restart (max attempts) (wait_for_restart_max_attempts) — after a reboot, Muppy tries to reach the server every 3 seconds and gives up after this number of attempts. Set to 0 to use the default of 170 attempts (approximately 8 min 30 sec).

Info

Firewall activation is decided at several levels: the global Settings, the Host, and the Server Type. Even with do_activate_ufw enabled, the firewall is only turned on during enrollment when the global setup_firewall_automatically_during_enrollment setting is on and the Host's "Don't activate FW at Enroll" flag is off.

System Server Types¶

Muppy ships a set of system Server Types (marked is_system). These are protected: non-admin users cannot modify them, and they cannot be deleted.

The seeded system Server Types are:

Server Type	Description
Azure	Generic Azure VMs.
OVH Public Cloud	Generic OVH Public Cloud instances.
Scaleway Instances	Generic Scaleway Compute "Instances".
LXC Container	LXD/LXC Linux containers.
LXC Virtual Machine	LXC Linux Virtual Machine containers.
Other	Any other host type.
Muppy Worker	Special host for the Muppy Workers.

Tip

Create your own (non-system) Server Type to capture a specific provider or hardware profile — for example Hstgr-KVM4 — and reuse it across Hosts that should be enrolled the same way.

Enroll Callback Tasks¶

Muppy lets you customize the Host enrollment process using a particular type of Task named Enroll Callback Task.

These callbacks are invoked at different steps of the enrollment process and let you adjust the system configuration of the Hosts:

Modifying partitions and mount points
Modifying system limits

Enroll Callback Tasks have a particular signature: a step parameter indicates at which stage of the enrollment process they are invoked.

Enroll Callback Task Example¶

@fabric_task()
def template_enroll_callback_task(
        cnx, host_obj,
        step:str,
        _imq_logger=None
    ):
    """ Template Enroll callback task
    :param step: The step whose end triggered this task:
       any of 'begin', 'apt_update_upgrade', 'install_mpy_required_packages', 
       'ufw_configure', 'collect_facts' and 'reboot'.
    :returns: any (not used)

    Database Environment is flushed and commited at Task end so you don't need 
    to do it.

    """
    odoo_env = host_obj.env
    _commit = odoo_env.cr.commit
    _task_logger = _imq_logger or _logger
    _task_logger.info("Processing Enrollment step '%s' on  host:'%s'.", step, host_obj)
    # ...
    return True

Implementation¶

Enroll Callback Tasks are attached to the Server Type (via its callback tasks) and invoked during enrollment execution.

Warning

There is no way to force the order in which callback tasks attached to the same Server Type are called.