openstack/bifrost
Code Issues Proposed changes

Merge "Revising dynamic config drive role README"

Browse Source
This commit is contained in:
Jenkins 2015-07-24 18:07:17 +00:00 committed by Gerrit Code Review
commit 36f4b5d339
1 changed files with 54 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

68
playbooks/roles/bifrost-configdrives-dynamic/README.md
View File

@ -6,25 +6,46 @@ Creates configdrives for nodes being provisioned in Bifrost.
Requirements
------------
This playbook is intended to be executed prior to the deployments of nodes via the bifrost-setup-nodes role, as part of Bifrost. It creates a basic configuration drive containing network configuration and an SSH key permitting the user to login to the host.
This playbook is intended to be executed prior to the deployments of nodes
via the bifrost-setup-nodes role, as part of Bifrost. It creates a basic
configuration drive containing network configuration and an SSH key
permitting the user to login to the host.
Role Variables
--------------
This role, like the other deployment related bifrost playbooks are expected to be executed with the bifrost dynamic inventory or a compatible configuration data source.
This role, like the other deployment related bifrost playbooks are expected
to be executed with the bifrost dynamic inventory or a compatible
configuration data source.
Additional key variables are:
addressing_mode: If defined and set to a value of "dhcp", this role sets the primary interface to utilize DHCP.
ipv4_subnet_mask: This is the subnet mask(e.g. 255.255.255.0 or similar) that matches the static addressing which desires to be imprinted into the configuration drive.
ipv4_gateway: This is the IPv4 default router address within the IPv4 subnet being utilized for IP addresses for the nodes being deployed.
addressing_mode: If defined and set to a value of "dhcp", this role sets the
primary interface to utilize DHCP.
ipv4_subnet_mask: This is the subnet mask(e.g. 255.255.255.0 or similar) that
matches the static addressing which desires to be imprinted
into the configuration drive.
ipv4_gateway: This is the IPv4 default router address within the IPv4 subnet
being utilized for IP addresses for the nodes being deployed.
ipv4_interface_mac: Optional: The MAC address of the network interface to
assign the IPv4 address to.
node_default_network_interface: This is the default network interface within the nodes to be deployed which the new IP configuration will be applied to. Note: This is likely to be deprecated and removed in the future as Bifrost will likely change methods utilized to include networking configuration into the configuration drive sufficiently that this should no longer be required.
ipv4_nameserver: Defines the IPv4 Nameserver to configure the node with initially in order to support name resolution.
node_default_network_interface: This is the default network interface within
the nodes to be deployed which the new IP
configuration will be applied to.
Note: This is likely to be deprecated and
removed in the future as Bifrost will likely
change methods utilized to include networking
configuration into the configuration drive
sufficiently that this should no longer be
required.
ipv4_nameserver: Defines the IPv4 Nameserver to configure the node with
initially in order to support name resolution.
ipv4_address: The IPv4 address of the node to be deployed, if applicable.
ssh_public_key_path: Defines the path to the file to be SSH public key to be inserted into the configuration drive.
ssh_public_key: If a user wishes to define an SSH public key as a string, this variable can be utilized which overrides ssh_public_key_path.
ssh_public_key_path: Defines the path to the file to be SSH public key to be
inserted into the configuration drive.
ssh_public_key: If a user wishes to define an SSH public key as a string,
this variable can be utilized which overrides the
ssh_public_key_path setting.
uuid: The UUID value for the node.
http_boot_folder: The folder where to save the configuration drive file to.
write_interfaces_file: Legacy option to write an debian style network
@ -39,18 +60,37 @@ node_network_info: Optional: If defined, the contents are written out to the
Customizing
-----------
The attempt with this playbook is to create a very simple and easily modifiable configuration drive to be loaded to the remote machine. This is done for each host that the role is run against.. If one wishes to insert additional files, this can be done by editing the tasks/main.yml file. As the drives are generated in a stepwise fashion, it is important to make note of and use the "{{ uuid }}" variable as that is utilized to delineate the file destinations between different configuration drives that may be in the process of being created.
The attempt with this playbook is to create a very simple and easily
modifiable configuration drive to be loaded to the remote machine.
This is done for each host that the role is run against. If one wishes
to insert additional files, this can be done by editing the tasks/main.yml
file. As the drives are generated in a stepwise fashion, it is important
to make note of and use the "{{ uuid }}" variable as that is utilized to
delineate the file destinations between different configuration drives
that may be in the process of being created.
Additional detail on the format of configuration drives can be found at http://docs.openstack.org/user-guide/content/enable_config_drive.html.
Additional detail on the format of configuration drives can be found at:
http://docs.openstack.org/user-guide/content/enable_config_drive.html
If one wishes to manually modify a configuration drive after the fact, the files are base64 encoded, gzip compressed, ISO9660 filesystems. Ironic will fail the deployment of the configuration drive if the file is not first found to be base64 encoded, and then gzip compressed. Alternatively, the configuration drive can be a vfat filesystem, although this carries with it some risks if the filesystem is always treated as a source of truth upon system boot.
If one wishes to manually modify a configuration drive after the fact,
the files are base64 encoded, gzip compressed, ISO9660 filesystems.
Ironic will fail the deployment of the configuration drive if the file
is not first found to be base64 encoded, and then gzip compressed.
Alternatively, the configuration drive can be a vfat filesystem,
although this carries with it some risks if the filesystem is always
treated as a source of truth upon system boot.
One final note. The size of the configuration drives is limited to 64MB. This is not a limit of Bifrost, but a limit due to the code utilized to write the configuration drive out.
One final note. The size of the configuration drives is limited to 64MB.
This is not a limit of Bifrost, but a limit due to the code utilized to
write the configuration drive out.
Dependencies
------------
This role is expected to be executed on a system that has had the ironic-install role executed upon it, however as the configuration drive creation step is fairly self contained, it can be executed as a separate step.
This role is expected to be executed on a system that has had the
ironic-install role executed upon it, however as the configuration
drive creation step is fairly self contained, it can be executed
as a separate step.
Example Playbook
----------------