On 12/02/2016 01:28 PM, Yolanda Robla Mota wrote:
Hi Dmitry
So we've been looking at that spec you suggested, but we are wondering if that
will be useful for our use case. As the text says:
The ``ironic-python-agent`` project and ``agent`` driver will be adjusted to
support ``get_deploy_steps``. That way, ``ironic-python-agent`` will be able
to declare deploy steps to run prior to disk imaging, and operators will be
able to extend ``ironic-python-agent`` to add any custom step.
Our needs are different, actually we need to create a deployment step after
imaging. We'd need an step that drops config on /etc/default/grub , and updates
it. This is a post-imaging deploy step, that modifies the base image. Could
ironic support these kind of steps, if there is a base system to just define
per-user steps?
I thought that all deployment operations are converted to steps, with
partitioning, writing the image, writing the configdrive and installing the boot
loader being four default ones (as you see, two steps actually happen after the
image is written).
The idea we had on mind is:
- from tripleo, add a property to each flavor, that defines the boot
parameters: openstack flavor set compute --property os:kernel_boot_params='abc'
- define a "ironic post-imaging deploy step", that will grab this property from
the flavor, drop it on /etc/default/grub and regenerate it
- then on local boot, the proper kernel parameters will be applied
What is your feedback there?
----- Original Message -----
From: "Dmitry Tantsur" <dtant...@redhat.com>
To: openstack-dev@lists.openstack.org
Sent: Friday, December 2, 2016 12:44:29 PM
Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel
parameters on local boot
On 11/28/2016 04:46 PM, Jay Faulkner wrote:
On Nov 28, 2016, at 7:36 AM, Yolanda Robla Mota <yrobl...@redhat.com> wrote:
Hi, good afternoon
I wanted to start an email thread about how to properly setup kernel parameters
on local boot, for our overcloud images on TripleO.
These parameters may vary depending on the needs of our end users, and even can
be different ( for different roles ) per deployment. As an example, we need it
for:
- enable FIPS kernel in terms of security
(https://bugs.launchpad.net/tripleo/+bug/1640235)
- enable functionality for DPDK/SR-IOV
(https://review.openstack.org/#/c/331564/)
- enable rd.iscsi.firmware=1 flag (this for the ramdisk image)
- etc..
So far, the solutions we got were on several directions:
1. Update the golden overcloud-full image with virt-customize, modifying
/etc/default/grub settings according to our needs: this is a manual process,
not really driven by TripleO. End users will want to avoid manual steps as much
as possible. Also if we announce that OpenStack ships features in TripleO like
DPDK, SR-IOV... doesn't make sense to tell end users that if they want to
consume that feature, they need to do manual updates on the image. It shall be
natively supported, or configurable per TripleO environments.
2. Create our own images using diskimage-builder and custom elements: in this
case, we have the problem that the partners will loose support, as building
their own images is good for upstream, but not accepted into the OSP
environment. Also the combination of images needed can be huge, that can be a
blocker for QA.
3. Add Ironic support for it. Images can be uploaded to glance, and some
properties can be set on metadata, like a json with kernel parameters. Ironic
will modify these kernel parameters when deploying the image (in a similar way
that when it installs bootloader, or generates partitions).
This has been proposed before in ironic-specs
(https://review.openstack.org/#/c/331564/) and was rejected, as it would
require Ironic to reach out and modify image contents, which traditionally has
been considered out of scope for Ironic. I would personally recommend #4, as
post-boot automation is the safest way to configure node-specific options
inside an image.
I'm still a bit divided about our decision back then.. On one hand, this does
seem somewhat out of scope. On the other, I quite understand why reboot is
suboptimal. I wonder if the ongoing deploy steps work will actually solve it by
allowing hardware managers to provide additional deploy steps.
Yolanda, you may want to check the spec https://review.openstack.org/#/c/382091/
as it lays the foundation for the deploy steps idea.
Thanks,
Jay Faulkner
OSIC
4. Configure it post-deployment: there can be some puppet element that updates
kernel parameters. But it will need a node reboot to be applied, and it's very
far from being optimal and acceptable for the end users. Reboots are slow, they
can be a problem depending on the number of nodes/hardware, and also the timing
of reboot shall be totally controlled (after all puppet has been applied
properly).
In the first three cases, we also hit the problem that TripleO only accepts one
single overcloud image for all deployments - there is no way to instruct
TripleO to upload and use several images, depending on the node type (although
Ironic supports it). Also, we are worried about upgrade paths if we do image
customizations. We need a clear way to move forward on it.
So, we'd like to discuss the possible options there and the action items to
take (raise bugs, create some blueprints...). To summarize, our end goal is the
following:
- need to map overcloud-full images to roles
- need to be done in an automated way, no manual steps enforced, and in a way
that can pass properly quality controls
- reboots are sub-optimal
What are your thoughts there?
Best,
Yolanda Robla
yrobl...@redhat.com
Principal Software Engineer - NFV Partner Engineer
__________________________________________________________________________
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
__________________________________________________________________________
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
