bosh-ironic-cpi-release | Managing baremetal servers with Bosh and Ironic | Cloud library

Focusing in Bosh v2 style manifests, before starting using the new Bosh Director, you have to upload a cloud-config definition to describe and use the infrastructure. Given the following example:. The sections are documented in https://bosh.io/docs/cloud-config.html , but there are cloud_properties parameters for some of them which have to be explained to understand the Bosh Ironic CPI functionalities. Take into account that some properties depend on your hardware and Ironic settings. Check the Ironic documentation to know more. To specifically define a server in Ironic, such server can be referenced in the deployment manifest. You can define as many servers as you need, and, in the same way Bosh CPI defines each server, it will be deleted from Ironic when it will be no longer needed in the deployment manifest. All the configuration remains in Bosh Cloud-Config. Two parameters must be defined in cloud properties: macs a list of all the MAC addresses of the physical server (even if they will not be used, in such case, an IP of the local loopback range will be assigned, see General considerations section above) and ironic_params is a dictionary of parameters for Ironic, basically the IPMI settings of the physical server and the image used to deploy the stemcell. ironic_params values depends on the physical server and Ironic configuration, it can include all the parameters supported by the ironic.node.create API method such as: chassis_uuid, driver, driver_info, extra, uuid, properties, name, network_interface, resource_class. The example configuration here should be enough for most of the cases, just change the MACs and the IPMI parameters acording to your server, for more information, check https://github.com/openstack/python-ironicclient/blob/master/ironicclient/v1/node.py and https://github.com/jriguera/ansible-ironic-standalone. To reference a predefined server by MAC. In this case, Bosh CPI will perform a search over all physical servers defined in Ironic which are in state available (not in use). Specific parameters of the selected server are already defined in Ironic (IPMI and driver_info settings) and Bosh CPI does not touch and know them. When the server is not longer needed by Bosh, it will be put in available state again, ready to be used. This mode is useful to target a specific server for a deployment. Only one parameter is needed: macs, a list of macs to search the server (or servers) pre-defined in Ironic. The first available server which has one of the MACs will be used.
To specifically define a server in Ironic, such server can be referenced in the deployment manifest. You can define as many servers as you need, and, in the same way Bosh CPI defines each server, it will be deleted from Ironic when it will be no longer needed in the deployment manifest. All the configuration remains in Bosh Cloud-Config. - name: pe-prod-dogo-lab-03 cloud_properties: macs: ['e4:1f:13:e6:3d:38', 'e4:1f:13:e6:3d:3a', '00:0a:cd:26:f2:1c', '00:0a:cd:26:f2:1b'] ironic_params: driver: "agent_ipmitool" driver_info: ipmi_address: "10.100.0.5" ipmi_username: "admin" ipmi_password: "pass" deploy_kernel: "file:///var/lib/ironic/http/deploy/ctinyipa-master.vmlinuz" deploy_ramdisk: "file:///var/lib/ironic/http/deploy/tinyipa-master.gz" Two parameters must be defined in cloud properties: macs a list of all the MAC addresses of the physical server (even if they will not be used, in such case, an IP of the local loopback range will be assigned, see General considerations section above) and ironic_params is a dictionary of parameters for Ironic, basically the IPMI settings of the physical server and the image used to deploy the stemcell. ironic_params values depends on the physical server and Ironic configuration, it can include all the parameters supported by the ironic.node.create API method such as: chassis_uuid, driver, driver_info, extra, uuid, properties, name, network_interface, resource_class. The example configuration here should be enough for most of the cases, just change the MACs and the IPMI parameters acording to your server, for more information, check https://github.com/openstack/python-ironicclient/blob/master/ironicclient/v1/node.py and https://github.com/jriguera/ansible-ironic-standalone
To reference a predefined server by MAC. In this case, Bosh CPI will perform a search over all physical servers defined in Ironic which are in state available (not in use). Specific parameters of the selected server are already defined in Ironic (IPMI and driver_info settings) and Bosh CPI does not touch and know them. When the server is not longer needed by Bosh, it will be put in available state again, ready to be used. This mode is useful to target a specific server for a deployment. - name: e4-1f-13-e6-3f-42 cloud_properties: macs: ['e4:1f:13:e6:3f:42'] Only one parameter is needed: macs, a list of macs to search the server (or servers) pre-defined in Ironic. The first available server which has one of the MACs will be used.
To define a pool of pre-defined servers by hardware properties. Similar to the previous use case, but instead of searching by MAC, Bosh CPI will search for a server which fits on the hardware properties required. The server has to be in manageable state to be selected. By using Ironic-Inspector to automatically discover and define the new servers in Ironic, without human intervention, they will become ready to use by Bosh CPI. Example: - name: pool cloud_properties: ironic_properties: local_gb: 500 cpus: 16 This will define a selection pool with two filters: local_gb wich will filter servers with at least 500 GB of disk storage and cpus which will select those ones with at least 16 cpus. The ironic_properties available are: memory_mb, cpu_arch, local_gb, cpus which are the same properties used by OpenStack Nova Scheduler as well the ones automatically defined by Ironic Inspector. When server is no longer needed, Bosh CPI will move it back to the pool.