[Rdo-list] introspection and raid configuration

Imre Farkas ifarkas at redhat.com
Wed May 27 10:30:13 UTC 2015


On 05/27/2015 11:38 AM, Dmitry Tantsur wrote:
> 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.
>

Yes, that was my thinking as well.

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




More information about the dev mailing list