Open Stack

This is a bit offtopic, but a couple of comments on BFV.

On 10/25/2017 03:55 PM, Derek Higgins wrote:
> On 25 October 2017 at 13:03, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>> (ooops, I somehow missed this email. sorry!)
>>
>> Hi Yolanda,
>>
>> On 10/16/2017 11:06 AM, Yolanda Robla Mota wrote:
>>>
>>> Hi
>>> Recently i've been helping some customers in the boot from ISCSI feature.
>>> So far everything was working, but we had a problem when booting the
>>> deployment image.
>>> It needed specifically a flag rd.iscsi.ibft=1 rd.iscsi.firmware=1 in the
>>> grub commands. But as the generated deployment image doesn't contain these
>>> flags, ISCSI was not booting properly. For other hardware setups, different
>>> flags may be needed.
>>
>>
>> Note that we only support BFV in the form of booting from a cinder volume
>> officially. We haven't looked into iBFV in depth.
>>
>>> The solution was to manually execute a virt-customize on the deployment
>>> image to hardcode these parameters.
>>> I wonder if we can add some feature in Ironic to support it. We have
>>> discussed about kernel parameters several times. But at this time, it
>>> affects ISCSI booting. Not having a way in Ironic to customize these
>>> parameters forces to manual workarounds.
>>
>>
>> This has been discussed several times, and every time the idea of making it
>> a generic feature was rejected. There is an option to configure kernel
>> parameters for PXE boot. However, apparently, you cannot add
>> rd.iscsi.firmware=1 if you don't use iSCSI, it will fail to boot (Derek told
>> me that, I did not check).
> When I tried it I got this
> [  370.704896] dracut-initqueue[387]: Warning: iscistart: Could not
> get list of targets from firmware.
> 
> perhaps we could alter iscistart to not complain if there are no
> targets attached and just continue, then simply always have
> rd.iscsi.firmware=1 in the kernel param regardless of storage type

I think we can fix ironic (the PXE boot interface) to pass this flag when using 
boot-from-volume, what do you think?

> 
>> If your deployment only uses iSCSI - you can
>> modify [pxe]pxe_append_params in your ironic.conf to include it.
> 
> I'm not sure this would help, in the boot from cinder volume case the
> iPXE script simply attaches the target and then hands control over to
> boot what ever is on the target. The kernel parameters use are already
> baked into the grub config. iPXE doesn't alter them and IPA isn't
> involved at all.
> 
> If anybody is looking to try any of this out in tripleo, here are some
> instructions to boot from cinder volume with ironic on a tripleo
> overcloud
> https://etherpad.openstack.org/p/tripleo-bfv

Nice! I think we should start moving it to tripleo-docs, when we figure out the 
problem above.

> 
>>
>>
>>> So can we reconsider the proposal to add kernel parameters there? It could
>>> be a settable argument (driver_info/kernel_args), and then the IPA could set
>>> the parameters properly on the image. Or any other option is welcome.
>>> What are your thoughts there?
>>
>>
>> Well, we could probably do that *for IPA only*. Something like
>> driver_info/deploy_image_append_params. This is less controversial than
>> doing that for user instances, as we fully control the IPA boot. If you want
>> to work on it, let's start with a detailed RFE please.
>>
>>>
>>> Thanks
>>>
>>> --
>>>
>>> Yolanda Robla Mota
>>>
>>> Principal Software Engineer, RHCE
>>>
>>> Red Hat
>>>
>>> <https://www.redhat.com>
>>>
>>> C/Avellana 213
>>>
>>> Urb Portugal
>>>
>>> yroblamo at redhat.com <mailto:yroblamo at redhat.com> M: +34605641639
>>> <http://redhatemailsignature-marketing.itos.redhat.com/>
>>>
>>> <https://red.ht/sig>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>