[openstack-dev] [ironic] Kernel parameters needed to boot from iscsi
juliaashleykreger at gmail.com
Mon Oct 30 15:16:30 UTC 2017
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: 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 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
>>>> So can we reconsider the proposal to add kernel parameters there? It
>>>> be a settable argument (driver_info/kernel_args), and then the IPA could
>>>> 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
>>> 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  and placing a grub-config
file . 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.
More information about the OpenStack-dev