> On Dec 2, 2016, at 3:44 AM, Dmitry Tantsur <dtant...@redhat.com> wrote: > > 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. >
I’m not really of two minds on this at all. Modifying the filesystem directly would expose Ironic to a whole new world of complexity, including security issues, dealing with multiple incompatible filesystems, and the like. I’m obviously OK if anyone wants to use a customization point to do stuff that’d typically be outside of Ironic’s scope, but I don’t think this is a use case we should encourage. The realm of configuring a machine beyond laying down the image has to lie in configuration management software, or else we open up to a huge scope increase and get away from our core mission. -Jay > 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
