If you wish to utilize ironic’s CLI in no-auth mode, you must set two environment variables:
IRONIC_URL
- A URL to the ironic API, such as http://localhost:6385/OS_AUTH_TOKEN
- Any value except empty space, such as ‘fake-token’,
is required to cause the client library to send requests directly to the API.For your ease of use, env-vars
can be sourced to allow the CLI to connect
to a local ironic installation operating in noauth mode. Run e.g.:
source env-vars
ironic node-list
+------+------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+------+------+---------------+-------------+--------------------+-------------+
+------+------+---------------+-------------+--------------------+-------------+
which should print an empty table if connection to Ironic works as expected.
The following requirements are installed during the install process as documented in the install documentation.
In order to enroll hardware, you will naturally need an inventory of your hardware. When utilizing the dynamic inventory module and accompanying roles the inventory can be supplied in one of three ways, all of which ultimately translate to JSON data that Ansible parses.
The original method is to utilize a CSV file. This format is covered below in the Legacy CSV File Format section. This has a number of limitations, but does allow a user to bulk load hardware from an inventory list with minimal data transformations.
The newer method is to utilize a JSON or YAML document which the inventory parser will convert and provide to Ansible.
In order to use, you will need to define the environment variable
BIFROST_INVENTORY_SOURCE
to equal a file, which then allows you to
execute Ansible utilizing the bifrost_inventory.py
file as the data
source.
The inventory/bifrost_inventory.py
program additionally features a
mode that allows a user to convert a CSV file to the JSON data format
utilizing a --convertcsv
command line setting when directly invoked.
Example:
export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.csv
inventory/bifrost_inventory.py --convertcsv >/tmp/baremetal.json
The JSON format closely resembles the data structure that ironic
utilizes internally. The name
, driver_info
, nics
,
driver
, and properties
fields are directly mapped through to
ironic. This means that the data contained within can vary from host
to host, such as drivers and their parameters thus allowing a mixed
hardware environment to be defined in a single file.
Example:
{
"testvm1": {
"uuid": "00000000-0000-0000-0000-000000000001",
"driver_info": {
"power": {
"ssh_port": 22,
"ssh_username": "ironic",
"ssh_virt_type": "virsh",
"ssh_address": "192.168.122.1",
"ssh_key_filename": "/home/ironic/.ssh/id_rsa"
}
},
"nics": [
{
"mac": "52:54:00:f9:32:f6"
}
],
"driver": "agent_ssh",
"ansible_ssh_host": "192.168.122.2",
"ipv4_address": "192.168.122.2",
"provisioning_ipv4_address": "10.0.0.9",
"properties": {
"cpu_arch": "x86_64",
"ram": "3072",
"disk_size": "10",
"cpus": "1"
},
"name": "testvm1"
}
}
The additional power of this format is easy configuration parameter injection,
which could potentially allow a user to provision different operating system
images onto different hardware chassis by defining the appropriate settings
in an instance_info
variable.
Examples utilizing JSON and YAML formatting, along host specific variable
injection can be found in the playbooks/inventory/
folder.
The CSV file has the following columns:
ipmi_target_channel
- Requires: ipmi_bridging
set to singleipmi_target_address
- Requires: ipmi_bridging
set to singleipmi_transit_channel
- Requires: ipmi_bridging
set to dualipmi_transit_address
- Requires: ipmi_bridging
set to dualExample definition:
00:11:22:33:44:55,root,undefined,192.168.122.1,1,8192,512,NA,NA,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,hostname_100,192.168.2.100,,,,agent_ipmitool,10.0.0.9
This file format is fairly flexible and can be easily modified although the enrollment and deployment playbooks utilize the model of a host per line model in order to process through the entire list, as well as reference the specific field items.
An example file can be found at: playbooks/inventory/baremetal.csv.example
Utilizing the dynamic inventory module, enrollment is as simple as setting
the BIFROST_INVENTORY_SOURCE
environment variable to your inventory data
source, and then executing the enrollment playbook.:
export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.json
ansible-playbook -vvvv -i inventory/bifrost_inventory.py enroll-dynamic.yaml
When ironic is installed on remote server, a regular ansible inventory with a target server should be added to ansible. This can be achieved by specifying a directory with files, each file in that directory will be part of the ansible inventory. Refer to ansible documentation http://docs.ansible.com/ansible/intro_dynamic_inventory.html#using-inventory-directories-and-multiple-inventory-sources
export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.json
rm inventory/*.example
ansible-playbook -vvvv -i inventory/ enroll-dynamic.yaml
Note that enrollment is a one-time operation. The Ansible module does not synchronize data for existing nodes. You should use the ironic CLI to do this manually at the moment.
Additionally, it is important to note that the playbooks for enrollment are
split into three separate playbooks based on the ipmi_bridging
setting.
After the nodes are enrolled, they can be deployed upon. Bifrost is geared to utilize configuration drives to convey basic configuration information to the each host. This configuration information includes an SSH key to allow a user to login to the system.
To utilize the newer dynamic inventory based deployment:
export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.json
ansible-playbook -vvvv -i inventory/bifrost_inventory.py deploy-dynamic.yaml
When ironic is installed on remote server, a regular ansible inventory with a target server should be added to ansible. This can be achieved by specifying a directory with files, each file in that directory will be part of the ansible inventory. Refer to ansible documentation http://docs.ansible.com/ansible/intro_dynamic_inventory.html#using-inventory-directories-and-multiple-inventory-sources
export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.json
rm inventory/*.example
ansible-playbook -vvvv -i inventory/ deploy-dynamic.yaml
Note:
Before running the above command, ensure that the value for `ssh_public_key_path` in
``./playbooks/inventory/group_vars/baremetal`` refers to a valid public key file,
or set the ssh_public_key_path option on the ansible-playbook command line by
setting the variable. Example: "-e ssh_public_key_path=~/.ssh/id_rsa.pub"
If the hosts need to be re-deployed, the dynamic redeploy playbook may be used:
export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.json
ansible-playbook -vvvv -i inventory/bifrost_inventory.py redeploy-dynamic.yaml
This playbook will undeploy the hosts, followed by a deployment, allowing a configurable timeout for the hosts to transition in each step.
A simple scripts/test-bifrost.sh
script can be utilized to install
pre-requisite software packages, Ansible, and then execute the
test-bifrost-create-vm.yaml
and test-bifrost.yaml
playbooks in order
to provide a single step testing mechanism.
playbooks/test-bifrost-create-vm.yaml
creates one or more VMs for
testing and saves out a baremetal.json file which is used by
playbooks/test-bifrost.yaml
to execute the remaining roles. Two
additional roles are invoked by this playbook which enables Ansible to
connect to the new nodes by adding them to the inventory, and then
logging into the remote machine via the user’s ssh host key. Once
that has successfully occurred, additional roles will unprovision the
host(s) and delete them from ironic.
Command:
scripts/test-bifrost.sh
Note:
test-bifrost.yaml
playbook due to the fact that is an IO-intensive operation that can
take a great deal of time.upper_constraints_file
setting is defined. This is consuming the UPPER_CONSTRAINTS_FILE
env
var by default, to properly integrate with CI systems, and will default
to /opt/stack/requirements/upper-constraints.txt
file if not present.Bifrost supports using virtual machines to emulate the hardware.
It is assumed you have an SSH server running on the host machine. The
agent_ssh
driver, used by ironic with VM testing, will need to use
SSH to control the virtual machines.
An SSH key is generated for the ironic
user when testing. The
ironic conductor will use this key to connect to the host machine and
run virsh commands.
testing
to true in the
playbooks/inventory/group_vars/target
file.ssh_public_key_path
.-e
testing=true
to the Ansible command line.ansible-playbook -vvvv -i inventory/target
test-bifrost-create-vm.yaml
command to create a test virtual
machine.BIFROST_INVENTORY_SOURCE
to the
path to the JSON file, which by default has been written to
/tmp/baremetal.json.By default, Bifrost deploys a configuration drive which includes the user SSH public key, hostname, and the network configuration in the form of network_data.json that can be read/parsed by the glean utility. This allows for the deployment of Ubuntu, CentOS, or Fedora “tenants” on baremetal. This file format is not yet supported by Cloud-Init, however it is on track for inclusion in cloud-init 2.0.
By default, Bifrost utilizes a utility called simple-init which leverages the previously noted glean utility to apply network configuration. This means that by default, root file systems may not be automatically expanded to consume the entire disk, which may, or may not be desirable depending upon operational needs. This is dependent upon what base OS image you utilize, and if the support is included in that image or not. At present, the standard Ubuntu cloud image includes cloud-init which will grow the root partition, however the ubuntu-minimal image does not include cloud-init and thus will not automatically grow the root partition.
Due to the nature of the design, it would be relatively easy for a user to import automatic growth or reconfiguration steps either in the image to be deployed, or in post-deployment steps via custom Ansible playbooks.
Bifrost supports the ability for a user to build a custom IPA ramdisk
utilizing the diskimage-builder element “ironic-agent”. In order to utilize
this feature, the download_ipa
setting must be set to false
and the
create_ipa_image must be set to “true”. By default, the install playbook will
build a Debian jessie based IPA image, if a pre-existing IPA image is not
present on disk. If you wish to explicitly set a specific release to be
passed to diskimage-create, then the setting dib_os_release
can be set in
addition to dib_os_element
.
If you wish to include an extra element into the IPA disk image, such as a
custom hardware manager, you can pass the variable ipa_extra_dib_elements
as a space-separated list of elements. This defaults to an empty string.
You can set up a static DHCP reservation using the ipv4_address
parameter
and setting the inventory_dhcp
setting to a value of true
. This will
result in the first MAC address defined in the list of hardware MAC addresses
to receive a static address assignment in dnsmasq.
dnsmasq will resolve all entries to the IP assigned to each server in
the leases file. However, this IP will not always be the desired one, if you
are working with multiple networks.
To force DNS to always resolve to ipv4_address
please set the
inventory_dns
setting to a value of true
. This will result in each
server to resolve to ipv4_address
by explicitly using address capabilities
of dnsmasq.
Bifrost manages the dnsmasq configuration file in /etc/dnsmasq.conf
. It is
not recommended to make manual modifications to this file after it has been
written. dnsmasq supports the use of additional configuration files in
/etc/dnsmasq.d
, allowing extension of the dnsmasq configuration provided by
bifrost. It is possible to use this mechanism provide additional DHCP options
to systems managed by ironic, or even to create a DHCP boot environment for
systems not managed by ironic. For example, create a file
/etc/dnsmasq.d/example.conf
with the following contents:
dhcp-match=set:<tag>,<match criteria>
dhcp-boot=tag:<tag>,<boot options>
The tag, match critera and boot options should be modified for your
environment. Here we use dnsmasq tags to match against hosts that we want to
manage. dnsmasq will use the last matching tagged dhcp-boot
option for a
host or an untagged default dhcp-boot
option if there were no matches.
These options will be inserted at the conf-dir=/etc/dnsmasq.d
line of the
dnsmasq configuration file. Once configured, send the HUP
signal to
dnsmasq, which will cause it to reread its configuration:
killall -HUP dnsmasq
The possibility exists that a user may already have a Dynamic Host Configuration Protocol (DHCP) server on their network.
Currently Ironic, when configured with Bifrost in standalone mode, does not utilize a DHCP provider. This would require a manual configuration of the DHCP server to deploy an image. Bifrost utilizes dnsmasq for this functionality; however, any DHCP server can be utilized. This is largely intended to function in the context of a single flat network although conceivably the nodes can be segregated.
What is required:
- DHCP server on the network segment
- Appropriate permissions to change DHCP settings
- Network access to the API and conductor. Keep in mind the iPXE image does not support ICMP redirects.
In the examples below port 8080 is used. However, the port number may vary depending on the environment configuration.
dnsmasq:
dhcp-match=set:ipxe,175 # iPXE sends a 175 option.
dhcp-boot=tag:ipxe,http://<Bifrost Host IP Address>:8080/boot.ipxe
dhcp-boot=/undionly.kpxe,<TFTP Server Hostname>,<TFTP Server IP Address>
Internet Systems Consortium DHCPd:
if exists user-class and option user-class = "iPXE" {
filename "http://<Bifrost Host IP Address>:8080/boot.ipxe";
} else {
filename "/undionly.kpxe";
next-server <TFTP Server IP Address>;
}
It should be emphasized that Ironic in standalone mode is intended to be used only in a trusted environment.
+-------------+
| DHCP Server |
+-------------+
|
+--------Trusted-Network----------+
| |
+-------------+ +-----------+
|Ironic Server| | Server |
+-------------+ +-----------+
Note
Use of keystone with bifrost is a very new feature and should be considered an advanced topic. Please feel free to reach out to the bifrost contributors and the ironic community as a whole in the project’s IRC channel.
Ultimately, as bifrost was designed for relatively short-lived
installations to facilitate rapid hardware deployment, the default
operating mode is referred to as noauth
mode. With that,
in order to leverage keystone authentication for the roles,
one of the following steps need to take place.
Update the role defaults for each role you plan to make use. This may not make much sense for most users, unless they are carrying such changes as downstream debt.
Invoke ansible-playbook with variables being set to override the default behavior. Example:
-e noauth_mode=false -e cloud_name=bifrost
Set the global defaults for tagret
(master/playbooks/inventory/group_vars/target
).
A user wishing to invoke OSC commands against the bifrost
installation, should set the OS_CLOUD
environment variable.
An example of setting the environment variable and then executing
the OSC command to list all baremetal nodes:
export OS_CLOUD=bifrost
openstack baremetal node list
Ironic, which is the underlying OpenStack component bifrost helps a user leverage, supports two different roles in keystone that helps govern the rights a user has in keystone.
These roles are baremetal_admin
and baremetal_observer
and a user can learn more about the roles from the ironic install
guide.
The OpenStack Ansible modules utilize os-client-config to obtain authentication details to connect to determine details.
If noauth_mode
is explicitly disabled, the bifrost roles that
speak with Ironic for actions such as enrollment of nodes and
deployment, automatically attempt to collect authentication
data from os-client-config. Largely these details are governed
as environment variables.
That being said, os-client-config supports the concept of clouds
and an a user can explicitly select the cloud they wish to deploy
to via the cloud_name
parameter.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.