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