On Fri, Dec 2, 2016 at 7:29 AM, Oliver Walsh <owa...@redhat.com> wrote: > 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. >
If this is physical hardware, the reboot can add 5-10+ minutes depending on the vendor. VM's aren't a good representation of the actual cost of a reboot. Thanks, -Alex > 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 <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). >> >> 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
