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? 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
