
Basically, there are three main installation scenario: Scenario 1: Ironic installation together with other openstack services including keystone. In this case variable enable_keystone is set to true and keystone service will be installed together with ironic installation. It is possible realise this scenario, no fix needed Scenario 2: Ironic installation with connection to already installed keystone. In this scenario we have to set enable_keystone to “No” to prevent from new keystone service installation during the ironic installation process. But in other hand, we need to have correct sections in ironic.conf to provide all information needed to connect to existing keystone. But all sections for keystone are added to ironic.conf only if enable_keystone var is set to “Yes”. It isn’t possible to realise this scenario. Proposed fix provide support for this scenario, where multiple regions share the same keystone service. Scenario 3: No keystone integration. Ironic don't connect to Keystone. It is possible realise this scenario, no fix needed Proposed solution also keep the default behaviour: if no enable_keystone_integration is manually defined by default it takes value of enable_keystone variable and all behaviour is the same. But if we don't want to install keystone and want to connect to existing one at the same time, it will be possible to set enable_keystone var to “No” (preventing keystone from installation) and at the same time set ironic_enable_keystone_integration to Yes to allow needed section appear in ironic.conf through templating. Change-Id: I0c7e9a28876a1d4278fb2ed8555c2b08472864b9
8.1 KiB
Ironic - Bare Metal provisioning
Overview
Ironic works well in Kolla, though it is not thoroughly tested as part of Kolla CI, so may be subject to instability.
Pre-deployment Configuration
Enable Ironic in /etc/kolla/globals.yml
:
enable_ironic: "yes"
In the same file, define a network interface as the default NIC for dnsmasq, a range of IP addresses that will be available for use by Ironic inspector, as well as a network to be used for the Ironic cleaning network:
ironic_dnsmasq_interface: "eth1"
ironic_dnsmasq_dhcp_range: "192.168.5.100,192.168.5.110"
ironic_cleaning_network: "public1"
In the same file, optionally a default gateway to be used for the Ironic Inspector inspection network:
ironic_dnsmasq_default_gateway: 192.168.5.1
In the same file, specify the PXE bootloader file for Ironic
Inspector. The file is relative to the /tftpboot
directory.
The default is pxelinux.0
, and should be correct for x86
systems. Other platforms may require a different value, for example
aarch64 on Debian requires
debian-installer/arm64/bootnetaa64.efi
.
ironic_dnsmasq_boot_file: pxelinux.0
Ironic inspector also requires a deploy kernel and ramdisk to be
placed in /etc/kolla/config/ironic/
. The following example
uses coreos which is commonly used in Ironic deployments, though any
compatible kernel/ramdisk may be used:
$ curl https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel \
-o /etc/kolla/config/ironic/ironic-agent.kernel
$ curl https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs \
-o /etc/kolla/config/ironic/ironic-agent.initramfs
You may optionally pass extra kernel parameters to the inspection kernel using:
ironic_inspector_kernel_cmdline_extras: ['ipa-lldp-timeout=90.0', 'ipa-collect-lldp=1']
in /etc/kolla/globals.yml
.
Enable iPXE booting (optional)
You can optionally enable booting via iPXE by setting
enable_ironic_ipxe
to true in
/etc/kolla/globals.yml
:
enable_ironic_ipxe: "yes"
When iPXE booting is enabled, the ironic_ipxe
container
is used to serve the iPXE boot images as described below. Regardless of
the setting above, the same container is used to support the
direct
deploy interface.
The port used for the iPXE webserver is controlled via
ironic_ipxe_port
in
/etc/kolla/globals.yml
:
ironic_ipxe_port: "8089"
The following changes will occur if iPXE booting is enabled:
- Ironic will be configured with the
ipxe_enabled
configuration option set to true - The inspection ramdisk and kernel will be loaded via iPXE
- The DHCP servers will be configured to chainload iPXE from an existing PXE environment. You may also boot directly to iPXE by some other means e.g by burning it to the option rom of your ethernet card.
Note that due to a limitation in Kolla Ansible, PXE and iPXE cannot be used together in a single deployment.
In order to enable the iPXE driver in Ironic, set the
[DEFAULT] enabled_boot_interfaces
option in
/etc/kolla/config/ironic.conf
:
[DEFAULT]
enabled_boot_interfaces = ipxe
Attach ironic to external keystone (optional)
In multi-regional <user/multi-regions.html>
deployment keystone could be installed in one region (let's say region
1) and ironic -in another region (let's say region 2). In this case we
don't install keystone together with ironic in region 2, but have to
configure ironic to connect to existing keystone in region 1. To deploy
ironic in this way we have to set variable enable_keystone
to "no"
.
enable_keystone: "no"
It will prevent keystone from being installed in region 2.
To add keystone-related sections in ironic.conf, it is also needed to
set variable ironic_enable_keystone_integration
to
"yes"
ironic_enable_keystone_integration: "yes"
Deployment
Run the deploy as usual:
$ kolla-ansible deploy
Post-deployment configuration
A script named init-runonce is supplied as part of kolla-ansible to initialise the cloud with some defaults (only to be used for demo purposes):
tools/init-runonce
The Ironic documentation <install/configure-glance-images>
describes how to create the deploy kernel and ramdisk and register them
with Glance. In this example we're reusing the same images that were
fetched for the Inspector:
openstack image create --disk-format aki --container-format aki --public \
--file /etc/kolla/config/ironic/ironic-agent.kernel deploy-vmlinuz
openstack image create --disk-format ari --container-format ari --public \
--file /etc/kolla/config/ironic/ironic-agent.initramfs deploy-initrd
The Ironic documentation <install/configure-nova-flavors>
describes how to create Nova flavors for bare metal. For example:
openstack flavor create --ram 512 --disk 1 --vcpus 1 my-baremetal-flavor
openstack flavor set my-baremetal-flavor --property \
resources:CUSTOM_BAREMETAL_RESOURCE_CLASS=1 \
resources:resources:VCPU=0 \
resources:resources:MEMORY_MB=0 \
resources:resources:DISK_GB=0
The Ironic documentation <install/enrollment>
describes how to enroll baremetal nodes and ports. In the following
example ensure to substitute correct values for the kernel, ramdisk, and
MAC address for your baremetal node.
openstack baremetal node create --driver ipmi --name baremetal-node \
--driver-info ipmi_port=6230 --driver-info ipmi_username=admin \
--driver-info ipmi_password=password \
--driver-info ipmi_address=192.168.5.1 \
--resource-class baremetal-resource-class --property cpus=1 \
--property memory_mb=512 --property local_gb=1 \
--property cpu_arch=x86_64 \
--driver-info deploy_kernel=15f3c95f-d778-43ad-8e3e-9357be09ca3d \
--driver-info deploy_ramdisk=9b1e1ced-d84d-440a-b681-39c216f24121
openstack baremetal port create 52:54:00:ff:15:55 \
--node 57aa574a-5fea-4468-afcf-e2551d464412 \
--physical-network physnet1
Make the baremetal node available to nova:
openstack baremetal node manage 57aa574a-5fea-4468-afcf-e2551d464412
openstack baremetal node provide 57aa574a-5fea-4468-afcf-e2551d464412
It may take some time for the node to become available for scheduling in nova. Use the following commands to wait for the resources to become available:
openstack hypervisor stats show
openstack hypervisor show 57aa574a-5fea-4468-afcf-e2551d464412
Booting the baremetal
You can now use the following sample command to boot the baremetal instance:
openstack server create --image cirros --flavor my-baremetal-flavor \
--key-name mykey --network public1 demo1
Notes
Debugging DHCP
The following tcpdump command can be useful when debugging why dhcp requests may not be hitting various pieces of the process:
tcpdump -i <interface> port 67 or port 68 or port 69 -e -n
Configuring the Web Console
Configuration based off upstream Node web console
<admin/console.html#node-web-console>
.
Serial speed must be the same as the serial configuration in the BIOS settings. Default value: 115200bps, 8bit, non-parity.If you have different serial speed.
Set ironic_console_serial_speed in
/etc/kolla/globals.yml
:
ironic_console_serial_speed: 9600n8