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 <dtant...@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

yrobl...@redhat.com <mailto:yrobl...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to