Re: [Rdo-list] introspection and raid configuration

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/

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