|
|
@ -72,8 +72,8 @@ Network Configuration |
|
|
|
##################### |
|
|
|
|
|
|
|
The ``.networking`` key defines the network topology of the site. Each |
|
|
|
subkey is the name of a network. Under each network name is a semi-recursive stanza |
|
|
|
defining the layer 2 and layer 3 attributes of the network: |
|
|
|
subkey is the name of a network. Under each network name is a semi-recursive |
|
|
|
stanza defining the layer 2 and layer 3 attributes of the network: |
|
|
|
|
|
|
|
.. code-block: json |
|
|
|
|
|
|
@ -114,18 +114,18 @@ or |
|
|
|
} |
|
|
|
|
|
|
|
|
|
|
|
* roles - These strings are used to select the correct network for internal gate |
|
|
|
functions - supported: "ssh", "dns", "bgp" |
|
|
|
* roles - These strings are used to select the correct network for internal |
|
|
|
gate functions - supported: "ssh", "dns", "bgp" |
|
|
|
* layer2 - Define Layer 2 attributes |
|
|
|
* layer3 - Valid if the ``layer2`` attribute is NOT defining VLANs, then define |
|
|
|
Layer 3 attributes. |
|
|
|
* layer3 - Valid if the ``layer2`` attribute is NOT defining VLANs, then |
|
|
|
define Layer 3 attributes. |
|
|
|
|
|
|
|
Disk Layouts |
|
|
|
############ |
|
|
|
|
|
|
|
The ``.disk_layouts`` key defines the various disk layouts that can be assigned |
|
|
|
to VMs being built. Each named layout key then defines one or more block devices |
|
|
|
that will be created as file-backed volumes. |
|
|
|
to VMs being built. Each named layout key then defines one or more block |
|
|
|
devices that will be created as file-backed volumes. |
|
|
|
|
|
|
|
.. code-block: json |
|
|
|
|
|
|
@ -154,20 +154,25 @@ that will be created as file-backed volumes. |
|
|
|
|
|
|
|
* size - Size of the volume in gigabytes |
|
|
|
* io_profile - One of the below I/O configurations |
|
|
|
* fast - In the case of a VM disruption, synchronous I/O may be lost. Better throughput. |
|
|
|
* fast - In the case of a VM disruption, synchronous I/O may be lost. |
|
|
|
Better throughput. |
|
|
|
* safe - Synchronous I/O fully written to disk, slower throughput. |
|
|
|
* bootstrap - For VMs that are bootstrapped by the framework, not Airship, use this disk |
|
|
|
* format - For VMs that are bootstrapped by the framework, describe how the disk should be |
|
|
|
formatted and mounted when desired. |
|
|
|
* unsafe - Host are caching all disk IO, and sync requests from VM are |
|
|
|
ignored. Max performance. |
|
|
|
* bootstrap - For VMs that are bootstrapped by the framework, not Airship, |
|
|
|
use this disk |
|
|
|
* format - For VMs that are bootstrapped by the framework, describe how the |
|
|
|
disk should be formatted and mounted when desired. |
|
|
|
* type - Filesystem type (e.g. 'xfs' or 'ext4') |
|
|
|
* mountpoint - Path to mountpoint |
|
|
|
|
|
|
|
VM Configuration |
|
|
|
################ |
|
|
|
|
|
|
|
Under the ``.vm`` key is a mapping of all the VMs that will be created via virt-install. |
|
|
|
This can be a mix of VMs that are bootstrapped via virsh/cloud-init and those deployed |
|
|
|
via Airship. Each key is the name of a VM and value is a JSON object: |
|
|
|
Under the ``.vm`` key is a mapping of all the VMs that will be created via |
|
|
|
virt-install. This can be a mix of VMs that are bootstrapped via |
|
|
|
virsh/cloud-init and those deployed via Airship. Each key is the name of a VM |
|
|
|
and value is a JSON object: |
|
|
|
|
|
|
|
.. code-block: json |
|
|
|
|
|
|
@ -214,20 +219,27 @@ via Airship. Each key is the name of a VM and value is a JSON object: |
|
|
|
* vcpus - Number of VM CPUs |
|
|
|
* sockets - Number of sockets. (Optional) |
|
|
|
* threads - Number of threads. (Optional) |
|
|
|
* disk_layout - A disk profile for the VM matching one defined under ``.disk_layouts`` |
|
|
|
* bootstrap - True/False for whether the framework should bootstrap the VM's OS |
|
|
|
* cpu_cells - Parameter to setup NUMA nodes and allocate RAM memory. (Optional) |
|
|
|
* disk_layout - A disk profile for the VM matching one defined under |
|
|
|
``.disk_layouts`` |
|
|
|
* bootstrap - True/False for whether the framework should bootstrap the |
|
|
|
VM's OS |
|
|
|
* cpu_cells - Parameter to setup NUMA nodes and allocate RAM memory. |
|
|
|
(Optional) |
|
|
|
* cpu_mode - CPU mode for the VM. (if not specified, default: host) |
|
|
|
* userdata - Cloud-init userdata to feed the VM when bootstrapped for further customization |
|
|
|
* networking - Network attachment and addressing configuration. Every key but ``addresses`` |
|
|
|
is assumed to be a desired NIC on the VM. For each NIC stanza, the following fields are respected: |
|
|
|
* userdata - Cloud-init userdata to feed the VM when bootstrapped for |
|
|
|
further customization |
|
|
|
* networking - Network attachment and addressing configuration. Every key |
|
|
|
but ``addresses`` is assumed to be a desired NIC on the VM. For each NIC |
|
|
|
stanza, the following fields are respected: |
|
|
|
|
|
|
|
* mac - A MAC address for the NIC |
|
|
|
* model - A model for the NIC (if not specified, default: virtio) |
|
|
|
* pci - A JSON object specifying ``slot`` and ``port`` specifying the PCI address for the NIC |
|
|
|
* pci - A JSON object specifying ``slot`` and ``port`` specifying the |
|
|
|
PCI address for the NIC |
|
|
|
* attachment - What network from ``.networking`` is attached to this NIC |
|
|
|
|
|
|
|
The ``addresses`` key specifies the IP address for each layer 3 network that the VM is attached to. |
|
|
|
The ``addresses`` key specifies the IP address for each layer 3 network |
|
|
|
that the VM is attached to. |
|
|
|
|
|
|
|
Stage Pipeline |
|
|
|
############## |
|
|
|