Bootstrap parameters are provided to the VM when the VM is created. They are used by the bootstrap process to configure various settings in the VM’s operating system.
On VMware, the bootstrap parameters are provided as vApp parameters. On OpenStack, the bootstrap parameters are provided as userdata in YAML format.
|
When using the Commissioning VM to deploy the VM in an automated way, the bootstrap parameters are automatically derived from the SDF. It is therefore not necessary to specify them manually, and in automated deployments this section is for reference only. |
Note on network interface parameters
The MAC address (OpenStack only), IP address, subnet mask and gateway parameters are specified per interface. Refer to Network Interfaces for a list of network interfaces found on each ShCM VM.
For VMware vApp parameters, each network interface property is prefixed by the name of the interface
and a full stop (.) - for example, management.ip_address.
For OpenStack userdata, the network interface properties for each interface are grouped into a YAML dictionary, whose key in the userdata is the name of the interface. For example:
management:
mac_address: AA:BB:CC:DD:EE:FF
ip_address: 192.168.10.10
subnet: 192.168.0.0/16
gateway: 192.168.1.1The names of the interfaces as used in the bootstrap parameters are as follows:
| Interface | Name used in vApp parameters or userdata |
|---|---|
Management |
|
Signaling |
|
See Network Interfaces for more information.
Writing the YAML userdata document for OpenStack
Userdata is a mechanism via which properties are provided to VM instances on OpenStack. For the ShCM and TSN VMs, userdata is provided in the form of a YAML document. You can find more information on YAML at https://yaml.org/spec/1.2/spec.html
In the list of bootstrap parameters, you can find the names of the parameters together with their format. Note that where a vApp parameter is specified as a comma-separated list for VMware, it should be converted to a YAML list for OpenStack. With the exception of network interfaces, all parameters are placed at the top level of the YAML document.
To provide the userdata to the OpenStack instances:
-
construct the YAML document in a single file, either directly on the OpenStack server, or by creating it on another machine and copying it to the OpenStack server; then
-
provide the
--user-data <file>parameter tonova bootduring instance creation, where<file>is the path to the file created in the previous step.
|
Since the files for different instances will be similar, but have different contents
(such as IP addresses), you may want to construct one file for each instance and name them
correspondingly, e.g. If you have a large number of VMs you may find it easier to write a script to generate the files. |
Below is a full example of a userdata YAML document. In particular note how each element of a list
is preceded by a hyphen (-), and that comments can be included by using the # character
(anything between the # and the end of that line is treated as a comment).
hostname: shcm-1
dns_servers:
- 8.8.8.8
- 8.8.4.4
ntp_servers:
- ntp1.telco.com
- ntp2.telco.com
timezone: Pacific/Auckland
cds_addresses:
- 192.168.10.10
- 192.168.10.11
- 192.168.10.12
deployment_id: telco1
site_id: DC01
# Network interface settings
management:
mac_address: AA:BB:CC:DD:EE:F0
ip_address: 192.168.10.10
subnet: 192.168.10.0/24
gateway: 192.168.10.1
signaling:
mac_address: AA:BB:CC:DD:EE:F1
ip_address: 192.168.20.10
subnet: 192.168.20.0/24
gateway: 192.168.20.1List of bootstrap parameters
| Property | Description | Format and Example |
|---|---|---|
|
Required. The hostname of the server. |
A string consisting of letters A-Z, a-z, digits 0-9, and hyphens (-). Maximum length is 27 characters. Example: |
|
Required. List of DNS servers. |
For VMware, a comma-separated list of IPv4 addresses. For OpenStack, a list of IPv4 addresses. Example: |
|
Required. List of NTP servers. |
For VMware, a comma-separated list of IPv4 addresses or FQDNs. For OpenStack, a list of IPv4 addresses or FQDNs. Example: |
|
Optional. The system time zone in POSIX format. Defaults to UTC. |
Example: |
|
Required. The list of signaling addresses of Config Data Store (CDS) servers which will provide initial configuration for the cluster. CDS is provided by the TSN nodes. Refer to the Initial Configuration section of the documentation for more information. |
For VMware, a comma-separated list of IPv4 addresses. For OpenStack, a list of IPv4 addresses. Example: |
|
Required. An identifier for this deployment. A deployment consists of one or more sites, each of which consists of several clusters of nodes. |
A string consisting of letters A-Z, a-z, digits 0-9, and hyphens (-). Maximum length is 15 characters. Example: |
|
Required. A unique identifier (within the deployment) for this site. |
A string of the form |
|
Required only when there are multiple clusters of the same type in the same site. A suffix to distinguish between clusters of the same node type within a particular site. For example, when deploying the MaX product, a second TSN cluster may be required. |
A string consisting of letters A-Z, a-z, and digits 0-9. Maximum length is 8 characters. Example: |
|
Optional. A list of SSH public keys. Machines configured with the corresponding private key will be allowed to access the node over SSH as the |
For VMware, a comma-separated list of SSH public key strings, including the For OpenStack, a list of SSH public key strings. Example: |
|
Required only on Openstack. The MAC address of the interface. |
Six pairs of hexadecimal digits separated by colons. Example: |
|
Required. The IPv4 address of the interface. |
IPv4 address in dotted-decimal notation. Example: |
|
Required. The subnet mask of the interface. |
IPv4 subnet mask in CIDR notation. Example: |
|
Required. The default gateway for traffic on the interface. |
IPv4 address in dotted-decimal notation. Example: |
