Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1533665 - root_device parameter not working in instackenv.json TripleO import file
root_device parameter not working in instackenv.json TripleO import file
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-common (Show other bugs)
10.0 (Newton)
x86_64 Linux
low Severity medium
: beta
: 13.0 (Queens)
Assigned To: Dmitry Tantsur
Alexander Chuzhoy
: Triaged
Depends On:
Blocks: 1473267
  Show dependency treegraph
 
Reported: 2018-01-11 17:21 EST by Philip Sweany
Modified: 2018-06-27 09:42 EDT (History)
7 users (show)

See Also:
Fixed In Version: openstack-tripleo-common-8.4.1-0.20180224032817.d51ed49.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-06-27 09:42:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1742905 None None None 2018-01-12 05:29 EST
OpenStack gerrit 533145 None master: MERGED tripleo-common: Add missing support for the root_device property (I4e9fbc940c424071206e96b3d90086282f381a9f) 2018-02-28 08:47 EST
Red Hat Product Errata RHEA-2018:2086 None None None 2018-06-27 09:42 EDT

  None (edit)
Description Philip Sweany 2018-01-11 17:21:49 EST
Description of problem:

The root_device parameter is not currently working/supported.  All other properties appear to work as documented.  My need is configure baremetal nodes and proceed directly to orchestration without performing introspection, in a classroom environment where all baremetal nodes are controlled, known-configuration KVM instances.

I am aware that this does work with a YAML file and "baremetal node create", but we are teaching TripleO and prefer using the instackenv.json type files for this section.  It also works properly to set the parameter using "baremetal node set" after the import, but the use case is to dynamically generate and invoke this json file, then go straight to orchestration.

Version-Release number of selected component (if applicable):

openstack-tripleo.noarch           0.0.8-0.2.4de13b3git.el7ost

How reproducible:

Steps to Reproduce:
1. Create an instackenv.json parameter file with the root_device parameter.  Syntax example here inline:

{
  "nodes": [
    {
      "name": "compute2",
      "pm_user": "admin",
      "arch": "x86_64",
      "mac": [ "52:54:00:00:f9:0d" ],
      "cpu": "2",
      "memory": "6144",
      "disk": "40",
      "pm_addr": "172.25.249.122",
      "pm_type": "pxe_ipmitool",
      "pm_password": "password",
      "capabilities": "profile:ceph-storage,boot_option:local",
      "root_device": {
         "name":"/dev/vda"
         }
  }
 ]
}




2. Perform "baremetal node import instackenv.json", which never completes.  Continuously retries and delays, unable to process the root_device parameter.

3. Abort the import, delete the baremetal node record partially created.

Actual results:

Import never completes.  Baremetal record is created with all other parameters, but not root_device.

Expected results:

The record is created with the root_device, as seen here:

[stack@director ~]$ openstack baremetal node show ceph0 -c properties
+------------+---------------------------------------------------------------------+
| Field      | Value                                                               |
+------------+---------------------------------------------------------------------+
| properties | {u'cpu_arch': u'x86_64', u'root_device': {u'name': u'/dev/vda'},    |
|            | u'cpus': u'2', u'capabilities': u'node:ceph0,boot_option:local',    |
|            | u'memory_mb': u'3072', u'local_gb': u'19'}                          |
+------------+---------------------------------------------------------------------+

Additional info:

Also, because the nodes are KVM instances (or other similar VMs), the root disk will always be the first virtual disk.  Hence our syntax where we will always set this to "name":"/dev/vda".  However, the root_device will need to be supported to work with all setting that are support by the current "baremetal node set --parameter" syntax that also works.
Comment 1 Dmitry Tantsur 2018-01-12 04:47:42 EST
Thanks!

> Continuously retries and delays, unable to process the root_device parameter

Could you please file a separate bug for this? Unexpected parameters should end up in a clear error message, not in this.
Comment 5 Alexander Chuzhoy 2018-05-07 11:19:41 EDT
Verified:

Environment: openstack-tripleo-common-8.6.1-6.el7ost.noarch

Imported instackenv.json with entry like below:

    "nodes": [
    {
      "name": "ceph-0",
      "mac": ["52:54:00:3a:a4:8e"],
      "cpu": "2",
      "memory": "4096",
      "root_device": {
         "name":"/dev/vdb"
         },
      "disk": "20",
            "arch": "x86_64",
              "pm_addr": "172.16.0.1",
        "pm_type": "pxe_ipmitool",
        "pm_user": "<user>",
        "pm_password": "<pass>",
        "pm_port": "6239"
          }, ]


Then checked for properties:


(undercloud) [stack@undercloud-0 ~]$ openstack baremetal node show ceph-0|grep properties
| properties             | {u'cpu_arch': u'x86_64', u'root_device': {u'name': u'/dev/vdb'}, u'cpus': u'2', u'capabilities': u'boot_option:local', u'memory_mb': u'4096', u'local_gb': u'20'}                                                                       |

the root_device is there as expected.
Comment 7 errata-xmlrpc 2018-06-27 09:42:10 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:2086

Note You need to log in before you can comment on or make changes to this bug.