2c1c54d7b7
The OpenStack CI systems are preconfigured with various components such as databases, message queues, caching dns resolvers. The CI systems also lack things like public/private key pairs, and known_hosts files. Due to this, a number of minor changes are required in Bifrost's test sequence to account for and route around these differences in order to allow test jobs to run until completion. This also demonstrated that some steps have been operating under the assumption that the user likely already had certain things installed, so service restart tweeks have also been necessary. Added a step to restart libvirt-bin in order to allow it to pickup new capabilities due to the install of the qemu emulator. Added additional steps to collect kernel log and `virsh capabilities` output. Removed MySQL step nolog statements as the password is automatically suppressed and it suppresses information that could be required for troubleshooting. Added in specific username/password logic for MySQL steps if ZUUL is detected in order to use the OpenStack CI defaults. Changed VM test node creation to occur upon every attempt. Extended the startup wait for a test node to be 900 seconds from 600 seconds. Added collection of process list and listening sockets if ZUUL is detected. Added report of VM console log and various commands to assist in troubleshooting a failing job. Added auto-generation of a user ssh keypair if absent when operating in OpenStack CI. Added explicit adjustment of iptables to permit connections on the network interface that the hosts are being provisioned via on 8080/tcp and 6385/tcp. Change-Id: I3c37c5c21af0aefb5007c5775043f7f837389c2d |
||
---|---|---|
.. | ||
defaults | ||
handlers | ||
meta | ||
tasks | ||
templates | ||
vars | ||
README.md |
bifrost-configdrives
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.
Role Variables
This role, like the other deployment related bifrost playbooks are intended to be executed with the "baremetal_csv_file" variable which points to the file used to define the enrolled nodes that wish to be deployed upon.
Additional key variables are:
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 configuraiton drive. ipv4_gateway: This is the IPv4 defaut router address with-in the IPv4 subnet being utilized for IP addresses for the nodes being deployed. node_default_network_interface: This is the default network interface with-in 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. ssh_public_key_path: Defines the path to the file to be SSH public key to be inserted into the configuraiton 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.
Customizing
The attempt with this playbook is to create a very simple and easilly modifable configuraiton drive to be loaded to the remote machine. This is naturally done each time the role is executed for every node defined in the baremetal_csv_file. 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 "{{item.split(',')[9]}}" variable as that is utilized to deliniate the file destinations between different configuration drives.
Additional detail on the format of configuraiton 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.
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.
Example Playbook
- hosts: localhost
connection: local
sudo: no
roles:
- role: bifrost-configdrives
License
Copyright (c) 2015 Hewlett-Packard Development Company, L.P.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express orimplied. See the License for the specific language governing permissions and limitations under the License.
Author Information
Ironic Developers