Hi Yolanda, I've the same requirements for a real-time compute role.
I'm current using #4. Puppet sets the kernel cmdline in /etc/defaults/grub, then touches a file that triggers a reboot in an os-refresh-config post-configure script. How much of an issue is the reboot? In my dev env it doesn't make a significant difference to the overall deployment time of a node. I'm thinking we could use #4 as the general solution. In cases where a reboot is too expensive then #1/#2/#3 could be used to prime the image with same /etc/default/grub that puppet would create. As puppet doesn't change it doesn't trigger a reboot. Re custom images. Support in python-tripleoclient could be improved but for now this is what I'm doing: Uploading a custom image: OS_IMAGE=custom-overcloud-full.qcow2 openstack overcloud image upload Set the Image for the custom role in param_defaults: parameter_defaults: CustomRoleImage: custom-overcloud-full Thanks, Ollie On 28 November 2016 at 15:36, Yolanda Robla Mota <[email protected]> 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). > > 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 > [email protected] > Principal Software Engineer - NFV Partner Engineer > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
