<div dir="ltr"><div><div>Yep, what Saravanan said is fine.<br></div>The idea i had on mind, is to drop the config on /etc/default/grub, so when ironic deploys the image and installs grub, the parameters are applied properly. We did some POCs with that in the past, and Ironic was booting the images with the right kernel params.<br></div>The documentation you talk about is how to do it now, but we have the hope it can change, because reboots can be problematic under some environments in production.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 13, 2016 at 12:28 PM, Oliver Walsh <span dir="ltr"><<a href="mailto:owalsh@redhat.com" target="_blank">owalsh@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Saravanan,<br>
<br>
Ah, ok. I'd assumed ironic didn't touch the bootloader as the docs<br>
show a mkconfig & reboot to customize grub for localboot:<br>
<a href="http://docs.openstack.org/project-install-guide/baremetal/draft/advanced.html#appending-kernel-parameters-to-boot-instances" rel="noreferrer" target="_blank">http://docs.openstack.org/<wbr>project-install-guide/<wbr>baremetal/draft/advanced.html#<wbr>appending-kernel-parameters-<wbr>to-boot-instances</a>.<br>
<br>
Thanks,<br>
Ollie<br>
<div class="HOEnZb"><div class="h5"><br>
On 13 December 2016 at 11:03, Saravanan KR <<a href="mailto:skramaja@redhat.com">skramaja@redhat.com</a>> wrote:<br>
> Hi Oliver,<br>
><br>
> During the deployment, Ironic will start the node with IPA ramdisk,<br>
> which will copy the overcloud image to the node's disk, then configure<br>
> the grub cfg [1], set the node to local boot and reboot the node.<br>
> After which the node will be boot with the overcloud image. So no<br>
> reboot required in the overcloud image, as the "deploy steps" will be<br>
> run by the IPA itself.<br>
><br>
> Regards,<br>
> Saravanan KR<br>
><br>
> [1] <a href="https://github.com/openstack/ironic-python-agent/blob/master/ironic_python_agent/extensions/image.py#L136" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>ironic-python-agent/blob/<wbr>master/ironic_python_agent/<wbr>extensions/image.py#L136</a><br>
><br>
><br>
> On Tue, Dec 13, 2016 at 4:18 PM, Oliver Walsh <<a href="mailto:owalsh@redhat.com">owalsh@redhat.com</a>> wrote:<br>
>> Hi Yolanda,<br>
>><br>
>>> these changes will be created by ironic before the image is deployed<br>
>><br>
>> The question I'm asking is how are the changed created without a reboot?<br>
>><br>
>> Typically when setting this via a manual change or via tuned the<br>
>> process is to modify /etc/default/grub, run grub2-mkconfig, and then<br>
>> reboot. Are you suggesting we drop in a pre-build grub cfg before<br>
>> deployment?<br>
>><br>
>> Thanks,<br>
>> Ollie<br>
>><br>
>> On 13 December 2016 at 10:33, Yolanda Robla Mota <<a href="mailto:yroblamo@redhat.com">yroblamo@redhat.com</a>> wrote:<br>
>>> It won't need a reboot, because these changes will be created by ironic<br>
>>> before the image is deployed. So it will boot with the right parameters. The<br>
>>> alternative of doing with puppet after the image was deployed, needed a<br>
>>> reboot, because the changes were done post-deploy.<br>
>>> So ironic build steps are pre-deploy without reboot, puppet changes are<br>
>>> post-deploy with a reboot.<br>
>>><br>
>>> On Tue, Dec 13, 2016 at 11:24 AM, Oliver Walsh <<a href="mailto:owalsh@redhat.com">owalsh@redhat.com</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> Saravanan wrote:<br>
>>>> > If ironic "deploy steps" can configure this "tuned" setting and run the<br>
>>>> > command<br>
>>>><br>
>>>> How does this avoid the reboot?<br>
>>>><br>
>>>> Yolanda wrote:<br>
>>>> > The idea will be to define custom deployment steps for ironic, like<br>
>>>> > including the kernel boot parameters.<br>
>>>><br>
>>>> Again, is this avoiding the reboot or just moving it?<br>
>>>><br>
>>>> Thanks,<br>
>>>> Ollie<br>
>>>><br>
>>>> On 13 December 2016 at 09:02, Saravanan KR <<a href="mailto:skramaja@redhat.com">skramaja@redhat.com</a>> wrote:<br>
>>>> > Hi Yolanda,<br>
>>>> ><br>
>>>> > The flow for "tuned" will be like set the "tuned" configuration files,<br>
>>>> > and then activate the profile by running the command "tuned-adm<br>
>>>> > tuned-profile-nfv". This command will actually write the required<br>
>>>> > configuration files for tuning the host. If ironic "deploy steps" can<br>
>>>> > configure this "tuned" setting and run the command, then it is good<br>
>>>> > enough.<br>
>>>> ><br>
>>>> > Regards,<br>
>>>> > Saravanan KR<br>
>>>> ><br>
>>>> > On Tue, Dec 13, 2016 at 1:04 PM, Yolanda Robla Mota<br>
>>>> > <<a href="mailto:yroblamo@redhat.com">yroblamo@redhat.com</a>> wrote:<br>
>>>> >> Hi Saravanan<br>
>>>> >> Thanks for your comments. With this new module, I guess a reboot is<br>
>>>> >> still<br>
>>>> >> needed after os-host-config ?<br>
>>>> >> Right now we have been guided by TripleO and Ironic people to start<br>
>>>> >> using<br>
>>>> >> what in Ironic is called "custom deployment steps". An initial spec is<br>
>>>> >> reflected here:<br>
>>>> >> <a href="https://review.openstack.org/#/c/382091" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/382091</a><br>
>>>> >><br>
>>>> >> The idea will be to define custom deployment steps for ironic, like<br>
>>>> >> including the kernel boot parameters. Can that be a solution for your<br>
>>>> >> "tuned" needs as well?<br>
>>>> >><br>
>>>> >> Best<br>
>>>> >> Yolanda<br>
>>>> >><br>
>>>> >> On Tue, Dec 13, 2016 at 7:59 AM, Saravanan KR <<a href="mailto:skramaja@redhat.com">skramaja@redhat.com</a>><br>
>>>> >> wrote:<br>
>>>> >>><br>
>>>> >>> Hello,<br>
>>>> >>><br>
>>>> >>> Thanks Yolanda for starting the thread. The list of requirements in<br>
>>>> >>> the host configuration, related to boot parameters and reboot are:<br>
>>>> >>><br>
>>>> >>> * DPDK - For vfio-pci driver binding, iommu support on kernel args is<br>
>>>> >>> mandatory, which has to be configured before os-net-config runs<br>
>>>> >>> * DPDK & RealTime - Enabling "tuned" profile for nfv or rt, will<br>
>>>> >>> update the boot parameters and a reboot is required<br>
>>>> >>> * Other items mentioned by Yolanda<br>
>>>> >>><br>
>>>> >>> If it is configuring only, the boot parameters, then ironic's deploy<br>
>>>> >>> feature may help, but there are other requirement to enable the<br>
>>>> >>> "tuned" profile which tunes the host for the required configuration,<br>
>>>> >>> which also requires reboot, as it will alter the boot parameters. If<br>
>>>> >>> we can collate the all the configurations which requires reboot<br>
>>>> >>> together, we will improve the reboot time. And if we reboot before the<br>
>>>> >>> actual openstack services are started, then the reboot time _may_<br>
>>>> >>> improve.<br>
>>>> >>><br>
>>>> >>> Can I propose a *new* module for TripleO deployments, like ><br>
>>>> >>> os-host-config <, which will run after os-collect-config and before<br>
>>>> >>> os-net-config, then we can collate all the host specific configuration<br>
>>>> >>> inside this module. This module can be a set of ansible scripts, which<br>
>>>> >>> will only configure the host. Ofcource the parameter to this module<br>
>>>> >>> should be provided via os-collect-config. Separating the host<br>
>>>> >>> configuration will help in the containerized TripleO deployment also.<br>
>>>> >>><br>
>>>> >>> Or any other better alternatives are welcome.<br>
>>>> >>><br>
>>>> >>> Please pour in your views if you think for/against it.<br>
>>>> >>><br>
>>>> >>> Regards,<br>
>>>> >>> Saravanan KR<br>
>>>> >>><br>
>>>> >>><br>
>>>> >>> On Fri, Dec 2, 2016 at 9:31 PM, Yolanda Robla Mota<br>
>>>> >>> <<a href="mailto:yroblamo@redhat.com">yroblamo@redhat.com</a>><br>
>>>> >>> wrote:<br>
>>>> >>> > Hi , Dmitry<br>
>>>> >>> > That's what i didn't get very clear. If all the deployment steps are<br>
>>>> >>> > pre-imaging as that statement says, or every deploy step could be<br>
>>>> >>> > isolated<br>
>>>> >>> > and configured somehow.<br>
>>>> >>> > I'm also a bit confused with that spec, because it mixes the concept<br>
>>>> >>> > of<br>
>>>> >>> > "deployment steps", will all the changes needed for runtime RAID.<br>
>>>> >>> > Could it<br>
>>>> >>> > be possible to separate into two separate ones?<br>
>>>> >>> ><br>
>>>> >>> > ----- Original Message -----<br>
>>>> >>> > From: "Dmitry Tantsur" <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>><br>
>>>> >>> > To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
>>>> >>> > Sent: Friday, December 2, 2016 3:51:30 PM<br>
>>>> >>> > Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update<br>
>>>> >>> > kernel<br>
>>>> >>> > parameters on local boot<br>
>>>> >>> ><br>
>>>> >>> > On 12/02/2016 01:28 PM, Yolanda Robla Mota wrote:<br>
>>>> >>> >> Hi Dmitry<br>
>>>> >>> >><br>
>>>> >>> >> So we've been looking at that spec you suggested, but we are<br>
>>>> >>> >> wondering<br>
>>>> >>> >> if that will be useful for our use case. As the text says:<br>
>>>> >>> >><br>
>>>> >>> >> The ``ironic-python-agent`` project and ``agent`` driver will be<br>
>>>> >>> >> adjusted to<br>
>>>> >>> >> support ``get_deploy_steps``. That way, ``ironic-python-agent``<br>
>>>> >>> >> will be<br>
>>>> >>> >> able<br>
>>>> >>> >> to declare deploy steps to run prior to disk imaging, and operators<br>
>>>> >>> >> will be<br>
>>>> >>> >> able to extend ``ironic-python-agent`` to add any custom step.<br>
>>>> >>> >><br>
>>>> >>> >> Our needs are different, actually we need to create a deployment<br>
>>>> >>> >> step<br>
>>>> >>> >> after imaging. We'd need an step that drops config on<br>
>>>> >>> >> /etc/default/grub ,<br>
>>>> >>> >> and updates it. This is a post-imaging deploy step, that modifies<br>
>>>> >>> >> the base<br>
>>>> >>> >> image. Could ironic support these kind of steps, if there is a base<br>
>>>> >>> >> system<br>
>>>> >>> >> to just define per-user steps?<br>
>>>> >>> ><br>
>>>> >>> > I thought that all deployment operations are converted to steps,<br>
>>>> >>> > with<br>
>>>> >>> > partitioning, writing the image, writing the configdrive and<br>
>>>> >>> > installing<br>
>>>> >>> > the boot<br>
>>>> >>> > loader being four default ones (as you see, two steps actually<br>
>>>> >>> > happen<br>
>>>> >>> > after the<br>
>>>> >>> > image is written).<br>
>>>> >>> ><br>
>>>> >>> >><br>
>>>> >>> >> The idea we had on mind is:<br>
>>>> >>> >> - from tripleo, add a property to each flavor, that defines the<br>
>>>> >>> >> boot<br>
>>>> >>> >> parameters:  openstack flavor set compute --property<br>
>>>> >>> >> os:kernel_boot_params='abc'<br>
>>>> >>> >> - define a "ironic post-imaging deploy step", that will grab this<br>
>>>> >>> >> property from the flavor, drop it on /etc/default/grub and<br>
>>>> >>> >> regenerate it<br>
>>>> >>> >> - then on local boot, the proper kernel parameters will be applied<br>
>>>> >>> >><br>
>>>> >>> >> What is your feedback there?<br>
>>>> >>> >><br>
>>>> >>> >> ----- Original Message -----<br>
>>>> >>> >> From: "Dmitry Tantsur" <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>><br>
>>>> >>> >> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
>>>> >>> >> Sent: Friday, December 2, 2016 12:44:29 PM<br>
>>>> >>> >> Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update<br>
>>>> >>> >> kernel<br>
>>>> >>> >> parameters on local boot<br>
>>>> >>> >><br>
>>>> >>> >> On 11/28/2016 04:46 PM, Jay Faulkner wrote:<br>
>>>> >>> >>><br>
>>>> >>> >>>> On Nov 28, 2016, at 7:36 AM, Yolanda Robla Mota<br>
>>>> >>> >>>> <<a href="mailto:yroblamo@redhat.com">yroblamo@redhat.com</a>><br>
>>>> >>> >>>> wrote:<br>
>>>> >>> >>>><br>
>>>> >>> >>>> Hi, good afternoon<br>
>>>> >>> >>>><br>
>>>> >>> >>>> I wanted to start an email thread about how to properly setup<br>
>>>> >>> >>>> kernel<br>
>>>> >>> >>>> parameters on local boot, for our overcloud images on TripleO.<br>
>>>> >>> >>>> These parameters may vary depending on the needs of our end<br>
>>>> >>> >>>> users,<br>
>>>> >>> >>>> and even can be different ( for different roles ) per deployment.<br>
>>>> >>> >>>> As an<br>
>>>> >>> >>>> example, we need it for:<br>
>>>> >>> >>>> - enable FIPS kernel in terms of security<br>
>>>> >>> >>>> (<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<br>
>>>> >>> >>>> (<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,<br>
>>>> >>> >>>> modifying /etc/default/grub settings according to our needs: this<br>
>>>> >>> >>>> is a<br>
>>>> >>> >>>> manual process, not really driven by TripleO. End users will want<br>
>>>> >>> >>>> to avoid<br>
>>>> >>> >>>> manual steps as much as possible. Also if we announce that<br>
>>>> >>> >>>> OpenStack ships<br>
>>>> >>> >>>> features in TripleO like DPDK, SR-IOV... doesn't make sense to<br>
>>>> >>> >>>> tell end<br>
>>>> >>> >>>> users that if they want to consume that feature, they need to do<br>
>>>> >>> >>>> manual<br>
>>>> >>> >>>> updates on the image. It shall be natively supported, or<br>
>>>> >>> >>>> configurable per<br>
>>>> >>> >>>> TripleO environments.<br>
>>>> >>> >>>><br>
>>>> >>> >>>> 2. Create our own images using diskimage-builder and custom<br>
>>>> >>> >>>> elements:<br>
>>>> >>> >>>> in this case, we have the problem that the partners will loose<br>
>>>> >>> >>>> support, as<br>
>>>> >>> >>>> building their own images is good for upstream, but not accepted<br>
>>>> >>> >>>> into the<br>
>>>> >>> >>>> OSP environment. Also the combination of images needed can be<br>
>>>> >>> >>>> huge, that can<br>
>>>> >>> >>>> be a blocker for QA.<br>
>>>> >>> >>>><br>
>>>> >>> >>>> 3. Add Ironic support for it. Images can be uploaded to glance,<br>
>>>> >>> >>>> and<br>
>>>> >>> >>>> some properties can be set on metadata, like a json with kernel<br>
>>>> >>> >>>> parameters.<br>
>>>> >>> >>>> Ironic will modify these kernel parameters when deploying the<br>
>>>> >>> >>>> image (in a<br>
>>>> >>> >>>> similar way that when it installs bootloader, or generates<br>
>>>> >>> >>>> partitions).<br>
>>>> >>> >>>><br>
>>>> >>> >>><br>
>>>> >>> >>> This has been proposed before in ironic-specs<br>
>>>> >>> >>> (<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<br>
>>>> >>> >>> would<br>
>>>> >>> >>> require Ironic to reach out and modify image contents, which<br>
>>>> >>> >>> traditionally<br>
>>>> >>> >>> has been considered out of scope for Ironic. I would personally<br>
>>>> >>> >>> recommend<br>
>>>> >>> >>> #4, as post-boot automation is the safest way to configure<br>
>>>> >>> >>> node-specific<br>
>>>> >>> >>> options inside an image.<br>
>>>> >>> >><br>
>>>> >>> >> I'm still a bit divided about our decision back then.. On one hand,<br>
>>>> >>> >> this does<br>
>>>> >>> >> seem somewhat out of scope. On the other, I quite understand why<br>
>>>> >>> >> reboot<br>
>>>> >>> >> is<br>
>>>> >>> >> suboptimal. I wonder if the ongoing deploy steps work will actually<br>
>>>> >>> >> solve it by<br>
>>>> >>> >> allowing hardware managers to provide additional deploy steps.<br>
>>>> >>> >><br>
>>>> >>> >> Yolanda, you may want to check the spec<br>
>>>> >>> >> <a href="https://review.openstack.org/#/c/382091/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/382091/</a><br>
>>>> >>> >> as it lays the foundation for the deploy steps idea.<br>
>>>> >>> >><br>
>>>> >>> >>><br>
>>>> >>> >>> Thanks,<br>
>>>> >>> >>> Jay Faulkner<br>
>>>> >>> >>> OSIC<br>
>>>> >>> >>><br>
>>>> >>> >>><br>
>>>> >>> >>>> 4. Configure it post-deployment: there can be some puppet element<br>
>>>> >>> >>>> that updates kernel parameters. But it will need a node reboot to<br>
>>>> >>> >>>> be<br>
>>>> >>> >>>> applied, and it's very far from being optimal and acceptable for<br>
>>>> >>> >>>> the end<br>
>>>> >>> >>>> users. Reboots are slow, they can be a problem depending on the<br>
>>>> >>> >>>> number of<br>
>>>> >>> >>>> nodes/hardware, and also the timing of reboot shall be totally<br>
>>>> >>> >>>> controlled<br>
>>>> >>> >>>> (after all puppet has been applied properly).<br>
>>>> >>> >>>><br>
>>>> >>> >>>><br>
>>>> >>> >>>> In the first three cases, we also hit the problem that TripleO<br>
>>>> >>> >>>> only<br>
>>>> >>> >>>> accepts one single overcloud image for all deployments - there is<br>
>>>> >>> >>>> no way to<br>
>>>> >>> >>>> instruct TripleO to upload and use several images, depending on<br>
>>>> >>> >>>> the node<br>
>>>> >>> >>>> type (although Ironic supports it). Also, we are worried about<br>
>>>> >>> >>>> upgrade paths<br>
>>>> >>> >>>> if we do image customizations. We need a clear way to move<br>
>>>> >>> >>>> forward on it.<br>
>>>> >>> >>>><br>
>>>> >>> >>>> So, we'd like to discuss the possible options there and the<br>
>>>> >>> >>>> action<br>
>>>> >>> >>>> items to take (raise bugs, create some blueprints...). To<br>
>>>> >>> >>>> summarize, our end<br>
>>>> >>> >>>> 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,<br>
>>>> >>> >>>> and<br>
>>>> >>> >>>> 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>
>>>> >>> >>>><br>
>>>> >>> >>>><br>
>>>> >>> >>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>>> >>> >>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> >>> >>>> Unsubscribe:<br>
>>>> >>> >>>> <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>
>>>> >>> >>><br>
>>>> >>> >>><br>
>>>> >>> >>> ______________________________<wbr>______________________________<wbr>______________<br>
>>>> >>> >>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> >>> >>> Unsubscribe:<br>
>>>> >>> >>> <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>
>>>> >>> >><br>
>>>> >>> >><br>
>>>> >>> >><br>
>>>> >>> >> ______________________________<wbr>______________________________<wbr>______________<br>
>>>> >>> >> OpenStack Development Mailing List (not for usage questions)<br>
>>>> >>> >> Unsubscribe:<br>
>>>> >>> >> <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>
>>>> >>> >><br>
>>>> >>> >> ______________________________<wbr>______________________________<wbr>______________<br>
>>>> >>> >> OpenStack Development Mailing List (not for usage questions)<br>
>>>> >>> >> Unsubscribe:<br>
>>>> >>> >> <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>
>>>> >>> ><br>
>>>> >>> ><br>
>>>> >>> ><br>
>>>> >>> > ______________________________<wbr>______________________________<wbr>______________<br>
>>>> >>> > OpenStack Development Mailing List (not for usage questions)<br>
>>>> >>> > Unsubscribe:<br>
>>>> >>> > <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>
>>>> >>> ><br>
>>>> >>> > ______________________________<wbr>______________________________<wbr>______________<br>
>>>> >>> > OpenStack Development Mailing List (not for usage questions)<br>
>>>> >>> > Unsubscribe:<br>
>>>> >>> > <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:<br>
>>>> >>> <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>
>>>> >><br>
>>>> >><br>
>>>> >> --<br>
>>>> >> Yolanda Robla Mota<br>
>>>> >> NFV Partner Engineer<br>
>>>> >> <a href="mailto:yroblamo@redhat.com">yroblamo@redhat.com</a><br>
>>>> >> <a href="tel:%2B34%20605641639" value="+34605641639">+34 605641639</a><br>
>>>> >><br>
>>>> >><br>
>>>> >> ______________________________<wbr>______________________________<wbr>______________<br>
>>>> >> OpenStack Development Mailing List (not for usage questions)<br>
>>>> >> Unsubscribe:<br>
>>>> >> <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>
>>>> ><br>
>>>> > ______________________________<wbr>______________________________<wbr>______________<br>
>>>> > OpenStack Development Mailing List (not for usage questions)<br>
>>>> > Unsubscribe:<br>
>>>> > <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>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Yolanda Robla Mota<br>
>>> NFV Partner Engineer<br>
>>> <a href="mailto:yroblamo@redhat.com">yroblamo@redhat.com</a><br>
>>> <a href="tel:%2B34%20605641639" value="+34605641639">+34 605641639</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>
>>><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>
<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"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Yolanda Robla Mota<br></div><div>NFV Partner Engineer<br></div><a href="mailto:yroblamo@redhat.com" target="_blank">yroblamo@redhat.com</a><br>+34 605641639<br></div></div>
</div>