URL:
Reporter RHNID: psweany
Section: -
Language: en-US (English)
Workaround:

Description: Submitted as Jira CL210-406 Setting baremetal node properties to avoid introspection

Useful "baremetal node properties" information for OpenStack instructors. Caution: because our classrooms use a proof-of-concept design built on KVM instances, not real hardware, this information has a limited scope and may not be appropriate for student production environments.

Properties for baremetal nodes, necessary to select nodes during orchestration, may be configured manually or by performing introspection on the live nodes. Creating and importing an instackenv file not only creates the baremetal node, but also loads the settings specified in the file as that node's properties. When introspection is performed, many of those properties are overwritten with new values learned during the introspection process.

There are a number of important points:

1) If you already know all of the node properties needed (e.g., cpu, memory, profile, disk, arch), introspection does not need to be performed. Enter the correct values in the instackenv file before importing, and then proceed directly to orchestration.

2) Any properties set using 'openstack baremetal node set' can be included in the instackenv file before importing. In many cases, all needed properties can be set this way, such that an admin can proceed immediately to the 'openstack overcloud deploy' directly after the 'baremetal node import'.

3) We use preconfigured, fixed size KVM domains as our baremetal nodes, which is why we know the node settings in advance. Production hardware may not be as consistent, requiring introspection to obtain accurate information about each node before orchestration.

4) When setting values manually, the values do not have to be exact, but should be realistic. THE VALUES IMPORTED INTO BAREMETAL NODE RECORD ARE ONLY USED DURING HOST SELECTION DURING ORCHESTRATION INITIALIZATION. The values manually entered must be sufficient to satisfy the flavor's minimum requirements, but are not used for any other purpose.

5) The 'capabilities' property is a multi-value record whose values must be set together. To change one value or to add a new capability requires rewriting all of the capabilities at one time with the 'capabilities' key. Any capabilities not included when writing a new record will be lost. This means that the 'capabilities' property manually entered into the instackenv file must include all necessary capability values, such as profile and boot_option.

Using the CL210 compute1 instackenv-onenode.json as an example:

In an instackenv file, these values are required:

     "name": "compute1",
     "pm_user": "admin",
     "pm_addr": "172.25.249.112",
     "pm_password": "password",
     "pm_type": "pxe_ipmitool",
     "mac": [
            "52:54:00:00:f9:0c"
            ],

Everything else could be learned through introspection, or added by 'baremetal node set' commands later. To avoid performing introspection, set these values:

     "arch": "x86_64",
     "cpu": "2",
     "memory": "6144",
     "disk": "40",

To avoid the 'baremetal node set' commands, set these optional capabilities, such as for compute1. Note that all capabilities are set on one line:

     "capabilities": "profile:compute,boot_option:local"

The ceph node needed to have the root disk forcibly declared. Here is the optional syntax for the instackenv file for ceph0:

     "capabilities": "profile:ceph-storage,boot_option:local"
     "root_device": {
                     "name": "'/dev/vda'"
                     }