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?

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

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.

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

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 >>>> >>> >> >