How to deploy machines
The ultimate purpose of MAAS is to deploy and manage machines. It’s important to understand how images get deployed – as explained in About the machine life-cycle, machines must first be enlisted or commissioned, then allocated, then deployed. This article will help you build on that understanding by explaining:
Note that if you are using your own commissioning scripts, and you do not want them to automatically run every time, you must specify noauto, as in this script snippet:
#!/bin/bash
#
# --- Start MAAS 1.0 script metadata ---
# name: 50-script-example
# title: Example
# description: Just an example
# script_type: commissioning
# tags: noauto
If you do not specify noauto, your custom commissioning scripts will run every time commissioning is attempted.
Once commissioned, you may consider adding a tag to this machine. The next step is testing and deployment.
This section explains:
You can also refer to technical details and examples for commissioning scripts and testing scripts as needed.
How to download built-in scripts
You can download the source for all commissioning and test scripts via the API with the following command:
maas $PROFILE node-script download $SCRIPT_NAME
The source code to all built-in scripts is available on launchpad.
Commissioning and testing script files may be found in the following directories:
/tmp/user_data.sh.*/scripts/commissioning/: Commissioning scripts/tmp/user_data.sh.*/scripts/testing/: Hardware testing scripts
Commissioning and testing log files may be found in the following directories:
/tmp/user_data.sh*/out//var/log/cloud-init-output.log/var/log/cloud-init.log
How to run all scripts manually
You can also run all commissioning and hardware-testing scripts on a machine for debugging.
/tmp/user_data.sh.*/bin/maas-run-remote-scripts \
[--no-download] \
[--no-send] \
/tmp/user_data.sh.*
Where:
--no-download: Optional. Do not download the scripts from MAAS again.--no-send: Optional. Do not send the results to MAAS.
For example, to run all the scripts again without downloading again from MAAS:
/tmp/user_data.sh.*/bin/maas-run-remote-scripts --no-download /tmp/user_data.sh.*
Here, all the scripts are run again after downloading from MAAS, but no output data is sent to MAAS:
/tmp/user_data.sh.*/bin/maas-run-remote-scripts --no-send /tmp/user_data.sh.*
MAAS can check whether links are connected or disconnected, so that you can detect unplugged cables. If you are not running MAAS 2.7 or higher, you must first upgrade and then recommission your machines to find disconnected links. MAAS not only reports unplugged cables, but also gives a warning when trying to configure a disconnected interface. In addition, administrators can change the cable connection status after manually resolving the issue.
Once you have manually repaired the broken connection, an administrator can change cable connection status:
How to detect slow network links
Administrators can change or update the link and interface speeds after manual changes to the connection:
maas $PROFILE interface update $SYSTEM_ID $INTERFACE_ID link_speed=$NEW_LINK_SPEED \
interface_speed=$NEW_INTERFACE_SPEED
This functionality is only available through the MAAS CLI.
How to configure network validation and testing scripts
MAAS allows you to configure network connectivity testing in a number of ways. If MAAS can’t connect to the rack controller, deployment can’t complete. MAAS can check connectivity to the rack controller and warn you if there’s no link, long before you have to try and debug it. For example, if you can’t connect to your gateway controller, traffic can’t leave your network.
Via the Web UI only, MAAS can check this link and recognise that there’s no connectivity, which alleviates hard-to-detect network issues:
Users can now test their network configuration to check for:
- Interfaces which have a broken network configuration
- Bonds that are not fully operational
- Broken gateways, rack controllers, and Internet links
In the ephemeral environment, standard DHCP is still applied, but when network testing runs, MAAS can apply your specific configuration for the duration of the test. While all URLs / IPs are tested with all interfaces, MAAS can test each of your interfaces individually, including breaking apart bonded NICS and testing each side of your redundant interfaces. You can also run different tests on each pass, e.g., a different set of URLs, although each run would be a different testing cycle.
To test individual interfaces, for example, you could issue the following CLI command:
Note that in this command, we are testing internet connectivity to the single interface “br0.”
How to customise network testing
MAAS allow you to customise network testing according to your needs. You can create your own commissioning scripts and tests related to networking, and you can run them during the network testing portion of the MAAS workflow.
There are no particular restrictions on these scripts, so you can test a wide variety of possible conditions and situations. Administrators can upload network tests and test scripts. Administrators can also create tests which accept an interface parameter, or scripts which apply custom network configurations.
Users can specify unique parameters using the API, override machines which fail network testing (allowing their use), and suppress individual failed network tests. Users can also review the health status from all interface tests, even sorting them by interface name and MAC. In addition, MAAS can report the overall status of all interfaces.
NOTE: To allocate a node, it must have a status of ‘Ready’.