How-To¶

Use the OpenStack CLI¶

If you wish to utilize the OpenStack CLI in no-auth mode, there are two options for configuring the authentication parameters.

export OS_CLOUD=bifrost
openstack baremetal node list

export OS_CLOUD=bifrost-inspector
openstack baremetal introspection list

. env-vars
openstack baremetal node list

Enroll Hardware¶

The following requirements are installed during the install process as documented in the install documentation.

• openstack/shade library
• openstack/os-client-config

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.

export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.csv
inventory/bifrost_inventory.py --convertcsv >/tmp/baremetal.json

{
    "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"
    }
}

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,,,,ipmi,10.0.0.9

export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.json
ansible-playbook -vvvv -i inventory/bifrost_inventory.py enroll-dynamic.yaml

export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.json
rm inventory/*.example
ansible-playbook -vvvv -i inventory/ enroll-dynamic.yaml

Deploy Hardware¶

export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.json
ansible-playbook -vvvv -i inventory/bifrost_inventory.py deploy-dynamic.yaml

export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.json
rm inventory/*.example
ansible-playbook -vvvv -i inventory/ deploy-dynamic.yaml

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"

export BIFROST_INVENTORY_SOURCE=/tmp/baremetal.json
ansible-playbook -vvvv -i inventory/bifrost_inventory.py redeploy-dynamic.yaml

Execute local testing¶

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:

• Cleaning mode is explicitly disabled in the test-bifrost.yaml playbook due to the fact that is an IO-intensive operation that can take a great deal of time.
• In order to cap requirements for installation, an 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.

Manually test with Virtual Machines¶

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.

1. Set testing to true in the playbooks/inventory/group_vars/target file.
2. You may need to adjust the value for ssh_public_key_path.
3. Run the install step, as documented above, however adding -e testing=true to the Ansible command line.
4. Execute the ansible-playbook -vvvv -i inventory/target test-bifrost-create-vm.yaml command to create a test virtual machine.
5. Set the environment variable of BIFROST_INVENTORY_SOURCE to the path to the JSON file, which by default has been written to /tmp/baremetal.json.
6. Run the enrollment step, as documented above, using the CSV file you created in the previous step.
7. Run the deployment step, as documented above.

Deployment and configuration of operating systems¶

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.

Build Custom Ironic Python Agent (IPA) images¶

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.

Configuring the integrated DHCP server¶

dhcp-match=set:<tag>,<match criteria>
dhcp-boot=tag:<tag>,<boot options>

killall -HUP dnsmasq

Using Bifrost with your own DHCP server¶

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.

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>

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>;
}

         +-------------+
         | DHCP Server |
         +-------------+
                |
+--------Trusted-Network----------+
       |                    |
+-------------+       +-----------+
|Ironic Server|       |   Server  |
+-------------+       +-----------+

Use Bifrost with Keystone¶

Bifrost execution with Keystone¶

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.

1. 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.

2. Invoke ansible-playbook with variables being set to override the default behavior. Example:

   -e noauth_mode=false -e cloud_name=bifrost
   

3. Set the global defaults for tagret (master/playbooks/inventory/group_vars/target).

export OS_CLOUD=bifrost
openstack baremetal node list

Individual playbook use with os-client-config¶

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.