<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 29, 2016 at 10:48 AM, Yolanda Robla Mota <span dir="ltr"><<a href="mailto:yroblamo@redhat.com" target="_blank">yroblamo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The problem we have with that is that for changes to take effect we will need a reboot after it.<br>
This is suboptimal for production environments, where there are large amount of nodes and with an slow hardware. And also the reboot needs to be carefully synced, to only take place after all puppet changes have been applied.<br>
That's why we wanted to consider some other solutions that are done pre-deployment, they will be much more effective in terms of performance.<br></blockquote><div><br></div><div>Would it be an option that Ironic provides those kernel params just for the first boot (when the overcloud is deployed) and TripleO then persists them by modifying grub.cfg accordingly for later local boots? This would avoid Ironic having to modify grub.cfg while also avoiding reboots.</div><div><br></div><div>However, those kernel params would need to be configurable per node / per role and ideally without duplicating the overcloud images in Glance.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
----- Original Message -----<br>
From: "Jay Faulkner" <jay@jvf.cc><br>
To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Sent: Monday, November 28, 2016 4:46:56 PM<br>
Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters        on local boot<br>
<br>
<br>
> On Nov 28, 2016, at 7:36 AM, Yolanda Robla Mota <<a href="mailto:yroblamo@redhat.com">yroblamo@redhat.com</a>> wrote:<br>
><br>
> Hi, good afternoon<br>
><br>
> I wanted to start an email thread about how to properly setup kernel parameters on local boot, for our overcloud images on TripleO.<br>
> 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:<br>
> - enable FIPS kernel in terms of security (<a href="https://bugs.launchpad.net/tripleo/+bug/1640235" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>tripleo/+bug/1640235</a>)<br>
> - enable functionality for DPDK/SR-IOV (<a href="https://review.openstack.org/#/c/331564/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/331564/</a>)<br>
> - enable rd.iscsi.firmware=1 flag (this for the ramdisk image)<br>
> - etc..<br>
><br>
> So far, the solutions we got were on several directions:<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
<br>
This has been proposed before in ironic-specs (<a href="https://review.openstack.org/#/c/331564/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/331564/</a>) 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.<br>
<br>
Thanks,<br>
Jay Faulkner<br>
OSIC<br>
<br>
<br>
> 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).<br>
><br>
><br>
> 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.<br>
><br>
> 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:<br>
><br>
> - need to map overcloud-full images to roles<br>
> - need to be done in an automated way, no manual steps enforced, and in a way that can pass properly quality controls<br>
> - reboots are sub-optimal<br>
><br>
> What are your thoughts there?<br>
><br>
> Best,<br>
><br>
><br>
> Yolanda Robla<br>
> <a href="mailto:yroblamo@redhat.com">yroblamo@redhat.com</a><br>
> Principal Software Engineer - NFV Partner Engineer<br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>{Kind regards | Mit besten Grüßen},<br><br>Frank<br><br>________________________________<br>Frank Zdarsky | NFV&SDN Technology&Standards Strategy | Office of Technology | Red Hat<br>e: <a href="mailto:fzdarsky@redhat.com" target="_blank">fzdarsky@redhat.com</a> | irc: fzdarsky@freenode | m: +49 175 82 11 64 4</div></div></div></div></div></div></div>
</div></div>