settingsLogin | Registersettings

[openstack-dev] [ironic] Kernel parameters needed to boot from iscsi

0 votes

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.
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.
So can we reconsider the proposal to add kernel parameters there? It could
be a settable argument (driverinfo/kernelargs), and then the IPA could
set the parameters properly on the image. Or any other option is welcome.
What are your thoughts there?

Thanks

--

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

https://www.redhat.com

C/Avellana 213

Urb Portugal

yroblamo@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Oct 30, 2017 in openstack-dev by yroblamo_at_redhat.c (1,040 points)   1 2

10 Responses

0 votes

Greetings Yolanda!

I guess I'm slightly not clear. In fact, I may be slightly even more
confused since we've discussed this directly. Thinking out loud, there are
two different scenarios of booting from iSCSI.

1) Human created/assigned/associated LUN off of a SAN which we want a node
to boot from, and that LUN lives onward as the "storage" for the node.

2) Cinder facilitated LUN off of $something that we want a node to boot
from. This largely would be the logic we added this past cycle to support
either booting via iPXE to iSCSI, or in the case of the iRMC driver, to set
the HBA to boot/attach from specific volumes.

I think your largely bringing up the first case when we speak of booting
from iSCSI. If not, then we technically haven't reached the point where we
are explicitly supporting hardware HBA use, but no time like the present!

Since there are many things here, I think we need to make sure we are
contextually on the same page. If any of this is wrong, please correct me:

  • You deploying a partition/filesystem image.
  • Ironic is partitioning and executing the installation of grub.
  • The scenario where your operating requires the boot loader command line
    to be updated with specific arguments.
  • Part of the problem is the ramdisk initialization where it is only honors
    arguments in your specific case.
  • Ironic does not presently provide a mechanism to append standard kernel
    arguments outside of netboot. Example from ages ago that many may remember,
    having to add noapic in some cases with a SMP kernel is to be used.

I believe it makes sense to have some sort of mechanism to append to the
default list in this case. There is the ansible deploy driver, but it seems
like that might be overkill for setting boot loader parameters, and Ironic
is explicitly executing grub-isntall.

I think the only reason we've resisted in supporting updating the defaults
file the past is because it would mean explicitly writing data to the grub
defaults file on the filesystem, I suspect our comfort level with
supporting that now may be different. In hindsight, considering we
essentially already support this with netboot but not local boot with a
partition image, I think we should add support for appending default
parameters.

Thoughts?

-Julia

On Mon, Oct 16, 2017 at 2:06 AM, Yolanda Robla Mota yroblamo@redhat.com
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.
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.
So can we reconsider the proposal to add kernel parameters there? It could
be a settable argument (driverinfo/kernelargs), and then the IPA could
set the parameters properly on the image. Or any other option is welcome.
What are your thoughts there?

Thanks

--

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

https://www.redhat.com

C/Avellana 213

Urb Portugal

yroblamo@redhat.com M: +34605641639

https://red.ht/sig


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 16, 2017 by Julia_Kreger (1,460 points)   3
0 votes

Hi Julia
Yes, you are right on your assumptions here. The missing feature here, is
the ability of Ironic to provide a mechanism to append standard kernel
arguments, when not netbooting. Having a way to append default parameters
to bootloader would be very useful and avoid the need of manual hacks, and
shouldn't be difficult to implement because Ironic is already interacting
with the bootloader.
How could we progress on that? Is some spec needed to provide this feature?

On Mon, Oct 16, 2017 at 9:29 PM, Julia Kreger juliaashleykreger@gmail.com
wrote:

Greetings Yolanda!

I guess I'm slightly not clear. In fact, I may be slightly even more
confused since we've discussed this directly. Thinking out loud, there are
two different scenarios of booting from iSCSI.

1) Human created/assigned/associated LUN off of a SAN which we want a node
to boot from, and that LUN lives onward as the "storage" for the node.

2) Cinder facilitated LUN off of $something that we want a node to boot
from. This largely would be the logic we added this past cycle to support
either booting via iPXE to iSCSI, or in the case of the iRMC driver, to set
the HBA to boot/attach from specific volumes.

I think your largely bringing up the first case when we speak of booting
from iSCSI. If not, then we technically haven't reached the point where we
are explicitly supporting hardware HBA use, but no time like the present!

Since there are many things here, I think we need to make sure we are
contextually on the same page. If any of this is wrong, please correct me:

  • You deploying a partition/filesystem image.
  • Ironic is partitioning and executing the installation of grub.
  • The scenario where your operating requires the boot loader command line
    to be updated with specific arguments.
  • Part of the problem is the ramdisk initialization where it is only
    honors arguments in your specific case.
  • Ironic does not presently provide a mechanism to append standard kernel
    arguments outside of netboot. Example from ages ago that many may remember,
    having to add noapic in some cases with a SMP kernel is to be used.

I believe it makes sense to have some sort of mechanism to append to the
default list in this case. There is the ansible deploy driver, but it seems
like that might be overkill for setting boot loader parameters, and Ironic
is explicitly executing grub-isntall.

I think the only reason we've resisted in supporting updating the defaults
file the past is because it would mean explicitly writing data to the grub
defaults file on the filesystem, I suspect our comfort level with
supporting that now may be different. In hindsight, considering we
essentially already support this with netboot but not local boot with a
partition image, I think we should add support for appending default
parameters.

Thoughts?

-Julia

On Mon, Oct 16, 2017 at 2:06 AM, Yolanda Robla Mota yroblamo@redhat.com
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.
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.
So can we reconsider the proposal to add kernel parameters there? It
could be a settable argument (driverinfo/kernelargs), and then the IPA
could set the parameters properly on the image. Or any other option is
welcome.
What are your thoughts there?

Thanks

--

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

https://www.redhat.com

C/Avellana 213

Urb Portugal

yroblamo@redhat.com M: +34605641639

https://red.ht/sig



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscrib
e
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

C/Avellana 213

Urb Portugal

yroblamo@redhat.com M: +34605641639


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 17, 2017 by yroblamo_at_redhat.c (1,040 points)   1 2
0 votes

(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). If
your deployment only uses iSCSI - you can modify [pxe]pxeappendparams in your
ironic.conf to include it.

So can we reconsider the proposal to add kernel parameters there? It could be a
settable argument (driverinfo/kernelargs), 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
driverinfo/deployimageappendparams. 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@redhat.com yroblamo@redhat.com M: +34605641639

https://red.ht/sig


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 25, 2017 by Dmitry_Tantsur (18,080 points)   2 3 7
0 votes

Answering inline...

Note that we only support BFV in the form of booting from a cinder volume
officially. We haven't looked into iBFV in depth.

I have been testing that on the context of booting from SAN. It is at
deploy time, in the context of TripleO, in the undercloud. At that point no
cinder is there. We have been deploying with some ISCSI targets, and ironic
consuming those instead of booting from local hard disk. I guess it is a
different context.

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). If your deployment only uses iSCSI - you
can modify [pxe]pxeappendparams in your ironic.conf to include it.

No PXE boot possible. As it is in the context of TripleO, we use the
boot_option=local. I know that it is possible to customize with pxe boot,
but we cannot rely on it, but have the kernel parameter on local boot.

Well, we could probably do that for IPA only. Something like
driverinfo/deployimageappendparams. 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.

IPA boot works fine. Some time ago I added some patches on the ironic-agent
element, to force the modprobe of several modules (including ibft, fcoe,
etc...) That is because IPA image is not based on dracut, so it doesn't
rely on parsing the cmdline from kernel boot and dracut hooks. The problem
with kernel parameters is only happening now on the deployment image, and
so far, the only working solution i could find, is execute a virt-customize
on the image to add those.

Thanks

--

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

https://www.redhat.com

C/Avellana 213

Urb Portugal

yroblamo@redhat.com yroblamo@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@lists.openstack.org?subject:unsubscrib
e
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

C/Avellana 213

Urb Portugal

yroblamo@redhat.com M: +34605641639


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 25, 2017 by yroblamo_at_redhat.c (1,040 points)   1 2
0 votes

On 10/25/2017 02:15 PM, Yolanda Robla Mota wrote:
Answering inline...

Note that we only support BFV in the form of booting from a cinder volume
officially. We haven't looked into iBFV in depth.

I have been testing that on the context of booting from SAN. It is at deploy
time, in the context of TripleO, in the undercloud. At that point no cinder is
there. We have been deploying with some ISCSI targets, and ironic consuming
those instead of booting from local hard disk. I guess it is a different context.

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). If your deployment only uses iSCSI - you can
modify [pxe]pxe_append_params in your ironic.conf to include it.

No PXE boot possible. As it is in the context of TripleO, we use the
boot_option=local. I know that it is possible to customize with pxe boot, but we
cannot rely on it, but have the kernel parameter on local boot.

Hmm, are we talking about IPA or user images? IPA always PXE boots, no matter
what bootoption we use. For user images with bootoption=local our only bet is
using the ansible deploy interface, I think (please review it!)

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.

IPA boot works fine. Some time ago I added some patches on the ironic-agent
element, to force the modprobe of several modules (including ibft, fcoe, etc...)
That is because IPA image is not based on dracut, so it doesn't rely on parsing
the cmdline from kernel boot and dracut hooks. The problem with kernel
parameters is only happening now on the deployment image, and so far, the only
working solution i could find, is execute a virt-customize on the image to add
those.

So, this is where the confusion probably is: "deployment image" is IPA. And by
the way the IPA image used in TripleO is based on dracut.

If you're talking about instance or user image, then, as I mention above, the
only option we have now is the ansible deploy interface.

    Thanks

    -- 

    Yolanda Robla Mota

    Principal Software Engineer, RHCE

    Red Hat

    <https://www.redhat.com>

    C/Avellana 213

    Urb Portugal

    yroblamo@redhat.com <mailto:yroblamo@redhat.com>
    <mailto:yroblamo@redhat.com <mailto:yroblamo@redhat.com>> M:
    +34605641639 <tel:%2B34605641639>
             >

    <https://red.ht/sig>


    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe:
    OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

https://www.redhat.com

C/Avellana 213

Urb Portugal

yroblamo@redhat.com yroblamo@redhat.com M: +34605641639

https://red.ht/sig


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 25, 2017 by Dmitry_Tantsur (18,080 points)   2 3 7
0 votes

Hmm, are we talking about IPA or user images? IPA always PXE boots, no
matter what bootoption we use. For user images with bootoption=local our
only bet is using the ansible deploy interface, I think (please review it!)

User images, i'm talking about user images (specifically about
overcloud-full image). I know ansible deploy driver will be an option, but
it will mean, that for booting from ISCSI with some specific hardware,
ansible deploy driver will be the only option possible. So exploring other
options as well, that could be simpler and will not restrict the driver.

So, this is where the confusion probably is: "deployment image" is IPA.
And by the way the IPA image used in TripleO is based on dracut.

That's specifically what made IPA agent work with ibft:

http://git.openstack.org/cgit/openstack/tripleo-image-elements/commit/?id=22a5e4e50f2bf2a71128614218ed208ee8f6f5c2

If you're talking about instance or user image, then, as I mention above,
the only option we have now is the ansible deploy interface.

    Thanks

    --
    Yolanda Robla Mota

    Principal Software Engineer, RHCE

    Red Hat

    <https://www.redhat.com>

    C/Avellana 213

    Urb Portugal

    yroblamo@redhat.com <mailto:yroblamo@redhat.com>
    <mailto:yroblamo@redhat.com <mailto:yroblamo@redhat.com>> M:
    +34605641639 <tel:%2B34605641639>
    >         >

    <https://red.ht/sig>


    ____________________________________________________________


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
____________________________________________________________


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.op
enstack.org?subject:unsubscribe

--

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

https://www.redhat.com

C/Avellana 213

Urb Portugal

yroblamo@redhat.com yroblamo@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@lists.openstack.org?subject:unsubscrib
e
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

C/Avellana 213

Urb Portugal

yroblamo@redhat.com M: +34605641639


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 25, 2017 by yroblamo_at_redhat.c (1,040 points)   1 2
0 votes

On 25 October 2017 at 13:03, Dmitry Tantsur dtantsur@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

If your deployment only uses iSCSI - you can
modify [pxe]pxeappendparams 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

So can we reconsider the proposal to add kernel parameters there? It could
be a settable argument (driverinfo/kernelargs), 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
driverinfo/deployimageappendparams. 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@redhat.com yroblamo@redhat.com M: +34605641639

https://red.ht/sig


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 25, 2017 by Derek_Higgins (5,340 points)   1 3 3
0 votes

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@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]pxeappendparams 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 (driverinfo/kernelargs), 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
driverinfo/deployimageappendparams. 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@redhat.com yroblamo@redhat.com M: +34605641639

https://red.ht/sig


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 25, 2017 by Dmitry_Tantsur (18,080 points)   2 3 7
0 votes

Sorry! A little late to the discussion with how busy I was last week.
Replies/thoughts in-line with trimmed text.

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

For those that haven't been following IRC discussion, Derek was kind
enough to submit a pull request to address this in dracut.

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

Not exactly. We perform iPXE sanhook attachments which causes iPXE to
speak iSCSI once we trigger boot. We have no means to pass kernel
arguments. We could rewrite the way the interface works to work more
like traditional linux netbooting where the linux kernel/ramdisk are
loaded up and arguments get passed on the kernel command line, but
then we are really Linux specific instead of booting whatever is on
the filesystem.

The other case to consider is outside our specific boot-from-volume
scenario. What if an operator chose to use a SAN system outside of
OpenStack's knowledge or control for root filesystems, and a parameter
is needed by the booting OS to see the storage hardware. If we don't
provide a mechanism, then the operator has no choice but to drive the
usage of highly specific "known-good" images for their baremetal cloud
tenants.

[trim]

So can we reconsider the proposal to add kernel parameters there? It
could
be a settable argument (driverinfo/kernelargs), 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
driverinfo/deployimageappendparams. 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.

I believe the reason we avoided providing the ability to pass
parameters to the deployed image when a partition image is used, was
because we wanted whatever was written to be pristine and unmodified
until it first booted, but I don't think the argument holds with the
way we presently operate by mounting 1 and placing a grub-config
file 2. Regardless of what we do on the filesystem, we still end up
changing filesystem metadata in this process because it is a
read/write mount for root partition that has been written out.

Personally, It feels like it wouldn't add much complexity to add a
file to /etc/grub.d or content to /etc/defaults/grub to facilitate
allowing an operator to pass standardized kernel parameters when
needed for their environment. Such a capability would realistically
help ease use of TripleO Overcloud deployments as well as bare metal
instance users when partition images are used. Of course, there is no
real option for a whole disk image to support doing such.

-Julia


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 30, 2017 by Julia_Kreger (1,460 points)   3
0 votes

On 30 October 2017 at 15:16, Julia Kreger juliaashleykreger@gmail.com wrote:
...

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

For those that haven't been following IRC discussion, Derek was kind
enough to submit a pull request to address this in dracut.

The relevant fix is here
https://github.com/dracutdevs/dracut/pull/298


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 1, 2017 by Derek_Higgins (5,340 points)   1 3 3
...