[Rdo-list] introspection and raid configuration

[Dmitry Tantsur]

On 05/27/2015 11:23 AM, Imre Farkas wrote:
> On 05/27/2015 09:50 AM, Dmitry Tantsur wrote:
>> On 05/27/2015 09:38 AM, Imre Farkas wrote:
>>> On 05/26/2015 05:43 PM, Dmitry Tantsur wrote:
>>>> On 05/26/2015 04:42 PM, Imre Farkas wrote:
>>>>> Hi all,
>>>>>
>>>>> I would like to gather some feedback on the current worfklow regarding
>>>>> the subject. RAID configuration on DRAC machines works as follows (it
>>>>> assumes there's no RAID volume on the machine):
>>>>> 1. user defines the deployment profile and the target raid
>>>>> configuration
>>>>> for each profile
>>>>> 2. ironic-discoverd introspects the node to gather facts
>>>>> 3. ach-match picks a deployment profile based on the gathered facts
>>>>> 4. instack triggers the raid configuration based on the selected
>>>>> profile
>>>>>
>>>>> A bug[1] has been discovered regarding step 2: ironic-discoverd fails
>>>>> because it tries to figure out the size of the local disk but it can't
>>>>> find any as no volume exists on the RAID controller yet. This is a
>>>>> chicken-and-egg problem because ironic-discoverd doesn't work if the
>>>>> RAID volume(s) has not been configured but the RAID configuration
>>>>> can't
>>>>> be triggered if ironic-discoverd hasn't gathered the facts about the
>>>>> node.
>>>>>
>>>>> Few possible workarounds:
>>>>> #1: make saving the local disk size optional in the standard plugin in
>>>>> ironic-discoverd. The downside is that the standard plugin is supposed
>>>>> to enroll nodes in ironic with all attributes necessary for
>>>>> scheduling.
>>>>> This assumption might fail with this solution.
>>>>
>>>> -1 will never get upstream for the reasons you stated
>>>>
>>>>>
>>>>> #2: run discovery multiple times with different set of plugins. The
>>>>> run
>>>>> before RAID configuration would exclude the standard plugin while the
>>>>> run afterwards could potentially exclude others. The parameters passed
>>>>> by the user to ironic-discoverd for each run need to be properly
>>>>> documented. It would slow down the installation because each run
>>>>> requires a reboot which takes a lot of time on bare metal.
>>>>
>>>> Possible, but better (IMO) idea below.
>>>>
>>>>>
>>>>> #3: name your suggestion!
>>>>
>>>> #3. modify your existing root_device_hint plugin to insert a fake
>>>> local_gb value (with issuing a warning), and then put it to the
>>>> beginning of the plugin pipeline. WDYT?
>>>>
>>>
>>> I would avoid that for the very same reason as we rejected option #1: it
>>> would do things quite differently than it is expected. However, building
>>> on top of this idea, we could introduce a fake_local_gb plugin and
>>> enable it as default in instack. Thoughts?
>>
>> ETOOMANYPLUGINS :D
>>
>> I would say it's fine for root_device_hint plugin. It's not enabled by
>> default upstream, and it's a normal flow involving it.
>>
>
> Patch proposed: https://review.openstack.org/#/c/185896/

Is it fine if we carry it downstream for some time? During rename I 
don't want to land anything upstream. I hope to be finished in a couple 
of days.

>
>>>
>>> Imre
>>>
>>>
>>>>>
>>>>> Any thoughts/preference on the above described workarounds?
>>>>>
>>>>> Thanks,
>>>>> Imre
>>>>>
>>>>>
>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1222124
>>>>
>>>
>>
>