<div dir="ltr"><p style="margin:0px 0px 14px;padding:0px;border:none;font-size:14px;line-height:1.4;font-family:"helvetica neue",arial,helvetica,sans-serif;color:rgb(82,82,82)">Hi,</p><p style="margin:0px 0px 14px;padding:0px;border:none;font-size:14px;line-height:1.4;font-family:"helvetica neue",arial,helvetica,sans-serif;color:rgb(82,82,82)"> I am trying to integrate ODL as external OVS manager and network controller but I could not mange to connect br-ex as ODL_BRIDGE_MAPPING with public interface eth2,</p><p style="margin:0px 0px 14px;padding:0px;border:none;font-size:14px;line-height:1.4;font-family:"helvetica neue",arial,helvetica,sans-serif;color:rgb(82,82,82)">ovs vsctl show:- Manager "tcp:<a href="http://192.67.27.27:6640">192.67.27.27:6640</a>" is_connected: true Manager "ptcp:6641:127.0.0.1" is_connected: true Bridge br-int Controller "tcp:<a href="http://192.67.27.27:6653">192.67.27.27:6653</a>" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal Port "tap95af7f98-35" Interface "tap95af7f98-35" type: internal Bridge br-ex Port br-ex Interface br-ex type: internal Port "eth2" Interface "eth2" ovs_version: "2.5.0"</p><p style="margin:0px 0px 14px;padding:0px;border:none;font-size:14px;line-height:1.4;font-family:"helvetica neue",arial,helvetica,sans-serif;color:rgb(82,82,82)">also it is creating two managers when I create network shown below:-</p><p style="margin:0px 0px 14px;padding:0px;border:none;font-size:14px;line-height:1.4;font-family:"helvetica neue",arial,helvetica,sans-serif;color:rgb(82,82,82)">. openrc admin admin openstack network create admin-external --external --provider-network-type flat --provider-physical-network public --provider-physical-network physnet1 openstack subnet create ext-subnet --network admin-external --allocation-pool start=192.67.20.29,end=192.67.20.69 --no-dhcp --gateway 192.67.10.10 --subnet-range <a href="http://192.67.27.0/24">192.67.27.0/24</a> openstack router create ext-rtr openstack router set ext-rtr --external-gateway admin-external openstack network create admin-internal --internal openstack subnet create vx-subnet --network admin-internal --subnet-range <a href="http://192.0.0.0/24">192.0.0.0/24</a> --dns-nameserver 192.67.10.10 neutron router-interface-add ext-rtr vx-subnet</p><p style="margin:0px 0px 14px;padding:0px;border:none;font-size:14px;line-height:1.4;font-family:"helvetica neue",arial,helvetica,sans-serif;color:rgb(82,82,82)">Is there any one face the same issues and would like to get some answers please!</p><p style="margin:0px;padding:0px;border:none;font-size:14px;line-height:1.4;font-family:"helvetica neue",arial,helvetica,sans-serif;color:rgb(82,82,82)">Kind Regards, Rahul</p></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 21, 2017 at 12:00 PM, <span dir="ltr"><<a href="mailto:openstack-operators-request@lists.openstack.org" target="_blank">openstack-operators-request@lists.openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-operators mailing list submissions to<br>
<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-operators-request@lists.openstack.org">openstack-operators-request@<wbr>lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-operators-owner@lists.openstack.org">openstack-operators-owner@<wbr>lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-operators digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Instances are not creating after adding 3 additional nova<br>
nodes (Kostyantyn Volenbovskyi)<br>
2. Re: Instances are not creating after adding 3 additional nova<br>
nodes (Kevin Benton)<br>
3. [osops][osops-tools-<wbr>monitoring] Updates for monitoring<br>
plugins (Major Hayden)<br>
4. [nova] Metadata service over virtio-vsock (Artom Lifshitz)<br>
5. Re: [nova] Metadata service over virtio-vsock (Clint Byrum)<br>
6. Re: [nova] Metadata service over virtio-vsock (Jeremy Stanley)<br>
7. Re: [nova] Metadata service over virtio-vsock (Clint Byrum)<br>
8. [publiccloud-wg]Atlanta Virtual PTG agenda (Zhipeng Huang)<br>
9. Re: [nova] Metadata service over virtio-vsock (Daniel P. Berrange)<br>
10. Re: [nova] Metadata service over virtio-vsock (Daniel P. Berrange)<br>
11. Re: [nova] Metadata service over virtio-vsock (Clint Byrum)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Mon, 20 Feb 2017 14:14:11 +0100<br>
From: Kostyantyn Volenbovskyi <<a href="mailto:volenbovsky@yandex.ru">volenbovsky@yandex.ru</a>><br>
To: Anwar Durrani <<a href="mailto:durrani.anwar@gmail.com">durrani.anwar@gmail.com</a>><br>
Cc: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] Instances are not creating after<br>
adding 3 additional nova nodes<br>
Message-ID: <<a href="mailto:04649DC8-CA9A-4EED-BC64-26BD02948F22@yandex.ru">04649DC8-CA9A-4EED-BC64-<wbr>26BD02948F22@yandex.ru</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
this 'Unexpected vif_type=binding_failed? is as well fairly-generic, but you can change focus from Nova to Neutron+virtual switch.<br>
<br>
So check:<br>
-Neutron server logs<br>
-Logs of Neutron agent on target Compute Host(s)<br>
-OVS logs and possibly things like /var/log/messages for things related to virtual networking.<br>
<br>
The root cause is typically:<br>
-misconfiguration of mechanism driver/type driver.<br>
-misconfiguration of virtual switching (typically OVS)<br>
Go through installation documents in <a href="http://docs.openstack.org" rel="noreferrer" target="_blank">docs.openstack.org</a>, that provides a guide for values<br>
parameters related to that.<br>
<br>
<br>
BR,<br>
Konstantin<br>
<br>
> On Feb 20, 2017, at 8:16 AM, Anwar Durrani <<a href="mailto:durrani.anwar@gmail.com">durrani.anwar@gmail.com</a>> wrote:<br>
><br>
> Further when i tried and attempt to launch new instance, i can see the following<br>
><br>
> tail -f /var/log/nova/nova-compute.log<br>
><br>
><br>
><br>
> 2017-02-20 12:45:26.596 5365 TRACE nova.compute.manager [instance: 1840ac2e-5a54-4941-a96f-<wbr>a431b2a2c236] flavor, virt_type)<br>
><br>
> 2017-02-20 12:45:26.596 5365 TRACE nova.compute.manager [instance: 1840ac2e-5a54-4941-a96f-<wbr>a431b2a2c236] File "/usr/lib/python2.7/site-<wbr>packages/nova/virt/libvirt/<wbr>vif.py", line 374, in get_config<br>
><br>
> 2017-02-20 12:45:26.596 5365 TRACE nova.compute.manager [instance: 1840ac2e-5a54-4941-a96f-<wbr>a431b2a2c236] _("Unexpected vif_type=%s") % vif_type)<br>
><br>
> 2017-02-20 12:45:26.596 5365 TRACE nova.compute.manager [instance: 1840ac2e-5a54-4941-a96f-<wbr>a431b2a2c236] NovaException: Unexpected vif_type=binding_failed<br>
><br>
> 2017-02-20 12:45:26.596 5365 TRACE nova.compute.manager [instance: 1840ac2e-5a54-4941-a96f-<wbr>a431b2a2c236]<br>
><br>
><br>
><br>
><br>
><br>
> On Mon, Feb 20, 2017 at 12:31 PM, Melvin Hillsman <<a href="mailto:mrhillsman@gmail.com">mrhillsman@gmail.com</a> <mailto:<a href="mailto:mrhillsman@gmail.com">mrhillsman@gmail.com</a>>> wrote:<br>
> Since the error was with scheduling you will want to modify the config for nova to show verbose output, try to create another instance, and check for the uuid and/or requestid of the creation attempt in the log - nova-scheduler.log<br>
><br>
> I would turn verbose logging off right after you get a failed attempt to schedule as well since they logs can grow quickly.<br>
><br>
> On Mon, Feb 20, 2017 at 12:56 AM, Saverio Proto <<a href="mailto:zioproto@gmail.com">zioproto@gmail.com</a> <mailto:<a href="mailto:zioproto@gmail.com">zioproto@gmail.com</a>>> wrote:<br>
> Well,<br>
> I have no idea from this log file. Trying to make nova-compute more<br>
> verbose if you dont find anything in the logs<br>
><br>
> Saverio<br>
><br>
> 2017-02-20 7:50 GMT+01:00 Anwar Durrani <<a href="mailto:durrani.anwar@gmail.com">durrani.anwar@gmail.com</a> <mailto:<a href="mailto:durrani.anwar@gmail.com">durrani.anwar@gmail.<wbr>com</a>>>:<br>
> ><br>
> > On Thu, Feb 16, 2017 at 1:44 PM, Saverio Proto <<a href="mailto:zioproto@gmail.com">zioproto@gmail.com</a> <mailto:<a href="mailto:zioproto@gmail.com">zioproto@gmail.com</a>>> wrote:<br>
> >><br>
> >> openstack server show uuid<br>
> ><br>
> ><br>
> > Hi Saverio,<br>
> ><br>
> > I have investigated and progressed the case as per your saying, i got to<br>
> > know that instance was supposed to be launched on one of the nova node,<br>
> > where i dig and tried find out log as you mentioned, following output i have<br>
> > seen as below :<br>
> ><br>
> > tail -f /var/log/nova/nova-compute.log<br>
> ><br>
> > 2017-02-20 10:40:19.318 5365 WARNING nova.compute.manager<br>
> > [req-34fa4448-061d-44ad-b6e9-<wbr>6ff0d1fd072f - - - - -] While synchronizing<br>
> > instance power states, found 4 instances in the database and 0 instances on<br>
> > the hypervisor.<br>
> ><br>
> > and<br>
> ><br>
> > other log where i have found following :<br>
> ><br>
> > tail -f /var/log/nova/nova-manage.log<br>
> ><br>
> > 2017-02-15 16:42:42.896 115003 TRACE nova File<br>
> > "/usr/lib/python2.7/site-<wbr>packages/eventlet/greenthread.<wbr>py", line 34, in<br>
> > sleep<br>
> ><br>
> > 2017-02-15 16:42:42.896 115003 TRACE nova hub.switch()<br>
> ><br>
> > 2017-02-15 16:42:42.896 115003 TRACE nova File<br>
> > "/usr/lib/python2.7/site-<wbr>packages/eventlet/hubs/hub.py"<wbr>, line 294, in switch<br>
> ><br>
> > 2017-02-15 16:42:42.896 115003 TRACE nova return self.greenlet.switch()<br>
> ><br>
> > 2017-02-15 16:42:42.896 115003 TRACE nova File<br>
> > "/usr/lib/python2.7/site-<wbr>packages/eventlet/hubs/hub.py"<wbr>, line 346, in run<br>
> ><br>
> > 2017-02-15 16:42:42.896 115003 TRACE nova self.wait(sleep_time)<br>
> ><br>
> ><br>
> > Thanks<br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Thanks & regards,<br>
> > Anwar M. Durrani<br>
> > +91-9923205011 <tel:099232%2005011><br>
> ><br>
> ><br>
><br>
> ______________________________<wbr>_________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a> <mailto:<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@<wbr>lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a>><br>
><br>
><br>
><br>
> --<br>
> Kind regards,<br>
><br>
> Melvin Hillsman<br>
> Ops Technical Lead<br>
> OpenStack Innovation Center<br>
><br>
> <a href="mailto:mrhillsman@gmail.com">mrhillsman@gmail.com</a> <mailto:<a href="mailto:mrhillsman@gmail.com">mrhillsman@gmail.com</a>><br>
> phone: (210) 312-1267<br>
> mobile: (210) 413-1659<br>
> <a href="http://osic.org" rel="noreferrer" target="_blank">http://osic.org</a> <<a href="http://osic.org/" rel="noreferrer" target="_blank">http://osic.org/</a>><br>
><br>
> Learner | Ideation | Belief | Responsibility | Command<br>
><br>
><br>
><br>
> --<br>
> Thanks & regards,<br>
> Anwar M. Durrani<br>
> <a href="tel:%2B91-9923205011" value="+919923205011">+91-9923205011</a><br>
> <<a href="http://in.linkedin.com/pub/anwar-durrani/20/b55/60b" rel="noreferrer" target="_blank">http://in.linkedin.com/pub/<wbr>anwar-durrani/20/b55/60b</a>><br>
><br>
> ______________________________<wbr>_________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a> <mailto:<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@<wbr>lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a>><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-operators/attachments/20170220/9b985588/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-operators/<wbr>attachments/20170220/9b985588/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 20 Feb 2017 08:31:40 -0500<br>
From: Kevin Benton <kevin@benton.pub><br>
To: Kostyantyn Volenbovskyi <<a href="mailto:volenbovsky@yandex.ru">volenbovsky@yandex.ru</a>><br>
Cc: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] Instances are not creating after<br>
adding 3 additional nova nodes<br>
Message-ID:<br>
<<a href="mailto:CAO_F6JMFSadCJx2isjZEBuSyPEAdzAi4t5pf7fTH74422jpXqg@mail.gmail.com">CAO_<wbr>F6JMFSadCJx2isjZEBuSyPEAdzAi4t<wbr>5pf7fTH74422jpXqg@mail.gmail.<wbr>com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Expanding on that, you get that binding error usually when Neutron thinks<br>
it can't wire up the ports on the compute nodes. So ensure that you started<br>
the appropriate Neutron agents on the new compute nodes and that they are<br>
alive by running 'neutron agent-list'.<br>
<br>
On Mon, Feb 20, 2017 at 8:14 AM, Kostyantyn Volenbovskyi <<br>
<a href="mailto:volenbovsky@yandex.ru">volenbovsky@yandex.ru</a>> wrote:<br>
<br>
> Hi,<br>
> this 'Unexpected vif_type=binding_failed? is as well fairly-generic, but<br>
> you can change focus from Nova to Neutron+virtual switch.<br>
><br>
> So check:<br>
> -Neutron server logs<br>
> -Logs of Neutron agent on target Compute Host(s)<br>
> -OVS logs and possibly things like /var/log/messages for things related to<br>
> virtual networking.<br>
><br>
> The root cause is typically:<br>
> -misconfiguration of mechanism driver/type driver.<br>
> -misconfiguration of virtual switching (typically OVS)<br>
> Go through installation documents in <a href="http://docs.openstack.org" rel="noreferrer" target="_blank">docs.openstack.org</a>, that provides a<br>
> guide for values<br>
> parameters related to that.<br>
><br>
><br>
> BR,<br>
> Konstantin<br>
><br>
> On Feb 20, 2017, at 8:16 AM, Anwar Durrani <<a href="mailto:durrani.anwar@gmail.com">durrani.anwar@gmail.com</a>><br>
> wrote:<br>
><br>
> Further when i tried and attempt to launch new instance, i can see the<br>
> following<br>
><br>
> tail -f /var/log/nova/nova-compute.log<br>
><br>
><br>
> 2017-02-20 12:45:26.596 5365 TRACE nova.compute.manager [instance:<br>
> 1840ac2e-5a54-4941-a96f-<wbr>a431b2a2c236] flavor, virt_type)<br>
><br>
> 2017-02-20 12:45:26.596 5365 TRACE nova.compute.manager [instance:<br>
> 1840ac2e-5a54-4941-a96f-<wbr>a431b2a2c236] File "/usr/lib/python2.7/site-<br>
> packages/nova/virt/libvirt/<wbr>vif.py", line 374, in get_config<br>
><br>
> 2017-02-20 12:45:26.596 5365 TRACE nova.compute.manager [instance:<br>
> 1840ac2e-5a54-4941-a96f-<wbr>a431b2a2c236] _("Unexpected vif_type=%s") %<br>
> vif_type)<br>
><br>
> 2017-02-20 12:45:26.596 5365 TRACE nova.compute.manager [instance:<br>
> 1840ac2e-5a54-4941-a96f-<wbr>a431b2a2c236] NovaException: Unexpected<br>
> vif_type=binding_failed<br>
><br>
> 2017-02-20 12:45:26.596 5365 TRACE nova.compute.manager [instance:<br>
> 1840ac2e-5a54-4941-a96f-<wbr>a431b2a2c236]<br>
><br>
><br>
><br>
> On Mon, Feb 20, 2017 at 12:31 PM, Melvin Hillsman <<a href="mailto:mrhillsman@gmail.com">mrhillsman@gmail.com</a>><br>
> wrote:<br>
><br>
>> Since the error was with scheduling you will want to modify the config<br>
>> for nova to show verbose output, try to create another instance, and check<br>
>> for the uuid and/or requestid of the creation attempt in the log -<br>
>> nova-scheduler.log<br>
>><br>
>> I would turn verbose logging off right after you get a failed attempt to<br>
>> schedule as well since they logs can grow quickly.<br>
>><br>
>> On Mon, Feb 20, 2017 at 12:56 AM, Saverio Proto <<a href="mailto:zioproto@gmail.com">zioproto@gmail.com</a>> wro<br>
>> te:<br>
>><br>
>>> Well,<br>
>>> I have no idea from this log file. Trying to make nova-compute more<br>
>>> verbose if you dont find anything in the logs<br>
>>><br>
>>> Saverio<br>
>>><br>
>>> 2017-02-20 7:50 GMT+01:00 Anwar Durrani <<a href="mailto:durrani.anwar@gmail.com">durrani.anwar@gmail.com</a>>:<br>
>>> ><br>
>>> > On Thu, Feb 16, 2017 at 1:44 PM, Saverio Proto <<a href="mailto:zioproto@gmail.com">zioproto@gmail.com</a>><br>
>>> wrote:<br>
>>> >><br>
>>> >> openstack server show uuid<br>
>>> ><br>
>>> ><br>
>>> > Hi Saverio,<br>
>>> ><br>
>>> > I have investigated and progressed the case as per your saying, i got<br>
>>> to<br>
>>> > know that instance was supposed to be launched on one of the nova node,<br>
>>> > where i dig and tried find out log as you mentioned, following output<br>
>>> i have<br>
>>> > seen as below :<br>
>>> ><br>
>>> > tail -f /var/log/nova/nova-compute.log<br>
>>> ><br>
>>> > 2017-02-20 10:40:19.318 5365 WARNING nova.compute.manager<br>
>>> > [req-34fa4448-061d-44ad-b6e9-<wbr>6ff0d1fd072f - - - - -] While<br>
>>> synchronizing<br>
>>> > instance power states, found 4 instances in the database and 0<br>
>>> instances on<br>
>>> > the hypervisor.<br>
>>> ><br>
>>> > and<br>
>>> ><br>
>>> > other log where i have found following :<br>
>>> ><br>
>>> > tail -f /var/log/nova/nova-manage.log<br>
>>> ><br>
>>> > 2017-02-15 16:42:42.896 115003 TRACE nova File<br>
>>> > "/usr/lib/python2.7/site-<wbr>packages/eventlet/greenthread.<wbr>py", line 34,<br>
>>> in<br>
>>> > sleep<br>
>>> ><br>
>>> > 2017-02-15 16:42:42.896 115003 TRACE nova hub.switch()<br>
>>> ><br>
>>> > 2017-02-15 16:42:42.896 115003 TRACE nova File<br>
>>> > "/usr/lib/python2.7/site-<wbr>packages/eventlet/hubs/hub.py"<wbr>, line 294, in<br>
>>> switch<br>
>>> ><br>
>>> > 2017-02-15 16:42:42.896 115003 TRACE nova return<br>
>>> self.greenlet.switch()<br>
>>> ><br>
>>> > 2017-02-15 16:42:42.896 115003 TRACE nova File<br>
>>> > "/usr/lib/python2.7/site-<wbr>packages/eventlet/hubs/hub.py"<wbr>, line 346, in<br>
>>> run<br>
>>> ><br>
>>> > 2017-02-15 16:42:42.896 115003 TRACE nova self.wait(sleep_time)<br>
>>> ><br>
>>> ><br>
>>> > Thanks<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > --<br>
>>> > Thanks & regards,<br>
>>> > Anwar M. Durrani<br>
>>> > +91-9923205011 <099232%2005011><br>
>>> ><br>
>>> ><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> OpenStack-operators mailing list<br>
>>> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Kind regards,<br>
>><br>
>> Melvin Hillsman<br>
>> Ops Technical Lead<br>
>> OpenStack Innovation Center<br>
>><br>
>> <a href="mailto:mrhillsman@gmail.com">mrhillsman@gmail.com</a><br>
>> phone: (210) 312-1267<br>
>> mobile: (210) 413-1659<br>
>> <a href="http://osic.org" rel="noreferrer" target="_blank">http://osic.org</a><br>
>><br>
>> Learner | Ideation | Belief | Responsibility | Command<br>
>><br>
><br>
><br>
><br>
> --<br>
> Thanks & regards,<br>
> Anwar M. Durrani<br>
> <a href="tel:%2B91-9923205011" value="+919923205011">+91-9923205011</a> <+91%2099232%2005011><br>
> <<a href="http://in.linkedin.com/pub/anwar-durrani/20/b55/60b" rel="noreferrer" target="_blank">http://in.linkedin.com/pub/<wbr>anwar-durrani/20/b55/60b</a>><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-operators/attachments/20170220/17883fb5/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-operators/<wbr>attachments/20170220/17883fb5/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 20 Feb 2017 12:00:35 -0500<br>
From: Major Hayden <<a href="mailto:major@mhtx.net">major@mhtx.net</a>><br>
To: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a><br>
Subject: [Openstack-operators] [osops][osops-tools-<wbr>monitoring] Updates<br>
for monitoring plugins<br>
Message-ID: <<a href="mailto:1263d686-af4a-b72a-2bca-188dbe525e62@mhtx.net">1263d686-af4a-b72a-2bca-<wbr>188dbe525e62@mhtx.net</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hey there,<br>
<br>
During the PTG, one of the discussions in the OpenStack-Ansible room was around adding a monitoring component to OSA. I found the 'osops-tools-monitoring' repository today.<br>
<br>
The idea we discussed was around writing plugins using the OpenStack SDK and then adding a simple library that outputs data based on the monitoring tools in use (like Nagios, Telegraf, etc). That would allow us to break apart the gathering of the metric (like checking Keystone's API response time) and the output of the metric (in the proper format for the tool).<br>
<br>
Would that work make sense within this repo or in a different one? Thanks!<br>
<br>
--<br>
Major Hayden<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 20 Feb 2017 13:22:36 -0500<br>
From: Artom Lifshitz <<a href="mailto:alifshit@redhat.com">alifshit@redhat.com</a>><br>
To: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a><br>
Subject: [Openstack-operators] [nova] Metadata service over<br>
virtio-vsock<br>
Message-ID:<br>
<<a href="mailto:CACqyMieod-E7XpdaKsr9RwqvB9dGGa5irRnNn4CCgEyDeszD9w@mail.gmail.com">CACqyMieod-<wbr>E7XpdaKsr9RwqvB9dGGa5irRnNn4CC<wbr>gEyDeszD9w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
We've been having a discussion [1] in openstack-dev about how to best<br>
expose dynamic metadata that changes over a server's lifetime to the<br>
server. The specific use case is device role tagging with hotplugged<br>
devices, where a network interface or volume is attached with a role<br>
tag, and the guest would like to know what that role tag is right<br>
away.<br>
<br>
The metadata API currently fulfills this function, but my<br>
understanding is that it's not hugely popular amongst operators and is<br>
therefore not universally deployed.<br>
<br>
Dan Berrange came up with an idea [2] to add virtio-vsock support to<br>
Nova. To quote his explanation, " think of this as UNIX domain sockets<br>
between the host and guest. [...] It'd likely address at least some<br>
people's security concerns wrt metadata service. It would also fix the<br>
ability to use the metadata service in IPv6-only environments, as we<br>
would not be using IP at all."<br>
<br>
So to those operators who are not deploying the metadata service -<br>
what are your reasons for doing so, and would those concerns be<br>
addressed by Dan's idea?<br>
<br>
Cheers!<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-February/112490.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>February/112490.html</a><br>
[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-February/112602.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>February/112602.html</a><br>
<br>
--<br>
Artom Lifshitz<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Mon, 20 Feb 2017 14:36:15 -0500<br>
From: Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
To: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [nova] Metadata service over<br>
virtio-vsock<br>
Message-ID: <<a href="mailto:1487619171-sup-3470@fewbar.com">1487619171-sup-3470@fewbar.<wbr>com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
What exactly is the security concern of the metadata service? Perhaps<br>
those concerns can be addressed directly?<br>
<br>
I ask because anything that requires special software on the guest is<br>
a non-starter IMO. virtio is a Linux thing, so what does this do for<br>
users of Windows? FreeBSD? etc.<br>
<br>
Excerpts from Artom Lifshitz's message of 2017-02-20 13:22:36 -0500:<br>
> We've been having a discussion [1] in openstack-dev about how to best<br>
> expose dynamic metadata that changes over a server's lifetime to the<br>
> server. The specific use case is device role tagging with hotplugged<br>
> devices, where a network interface or volume is attached with a role<br>
> tag, and the guest would like to know what that role tag is right<br>
> away.<br>
><br>
> The metadata API currently fulfills this function, but my<br>
> understanding is that it's not hugely popular amongst operators and is<br>
> therefore not universally deployed.<br>
><br>
> Dan Berrange came up with an idea [2] to add virtio-vsock support to<br>
> Nova. To quote his explanation, " think of this as UNIX domain sockets<br>
> between the host and guest. [...] It'd likely address at least some<br>
> people's security concerns wrt metadata service. It would also fix the<br>
> ability to use the metadata service in IPv6-only environments, as we<br>
> would not be using IP at all."<br>
><br>
> So to those operators who are not deploying the metadata service -<br>
> what are your reasons for doing so, and would those concerns be<br>
> addressed by Dan's idea?<br>
><br>
> Cheers!<br>
><br>
> [1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-February/112490.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>February/112490.html</a><br>
> [2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-February/112602.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>February/112602.html</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Mon, 20 Feb 2017 20:08:00 +0000<br>
From: Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>><br>
To: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [nova] Metadata service over<br>
virtio-vsock<br>
Message-ID: <<a href="mailto:20170220200800.GB12827@yuggoth.org">20170220200800.GB12827@<wbr>yuggoth.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On 2017-02-20 14:36:15 -0500 (-0500), Clint Byrum wrote:<br>
> What exactly is the security concern of the metadata service? Perhaps<br>
> those concerns can be addressed directly?<br>
[...]<br>
<br>
A few I'm aware of:<br>
<br>
1. It's something that runs in the control plane but needs to be<br>
reachable from untrusted server instances (which may themselves even<br>
want to be on completely non-routed networks).<br>
<br>
2. If you put a Web proxy between your server instances and the<br>
metadata service and also make it reachable without going through<br>
that proxy then instances may be able to spoof one another<br>
(OSSN-0074).<br>
<br>
3. Lots of things, for example facter, like to beat on it heavily<br>
which makes for a fun DDoS and so is a bit of a scaling challenge in<br>
large deployments.<br>
<br>
There are probably plenty more I don't know since I'm not steeped in<br>
operating OpenStack deployments.<br>
--<br>
Jeremy Stanley<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Mon, 20 Feb 2017 16:03:01 -0500<br>
From: Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
To: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [nova] Metadata service over<br>
virtio-vsock<br>
Message-ID: <<a href="mailto:1487624452-sup-6552@fewbar.com">1487624452-sup-6552@fewbar.<wbr>com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Excerpts from Jeremy Stanley's message of 2017-02-20 20:08:00 +0000:<br>
> On 2017-02-20 14:36:15 -0500 (-0500), Clint Byrum wrote:<br>
> > What exactly is the security concern of the metadata service? Perhaps<br>
> > those concerns can be addressed directly?<br>
> [...]<br>
><br>
> A few I'm aware of:<br>
><br>
<br>
Thanks!<br>
<br>
> 1. It's something that runs in the control plane but needs to be<br>
> reachable from untrusted server instances (which may themselves even<br>
> want to be on completely non-routed networks).<br>
><br>
<br>
As is DHCP<br>
<br>
> 2. If you put a Web proxy between your server instances and the<br>
> metadata service and also make it reachable without going through<br>
> that proxy then instances may be able to spoof one another<br>
> (OSSN-0074).<br>
><br>
<br>
That's assuming the link-local approach used by the EC2 style service.<br>
<br>
If you have DHCP hand out a metadata URL with a nonce in it, that's no<br>
longer an issue.<br>
<br>
> 3. Lots of things, for example facter, like to beat on it heavily<br>
> which makes for a fun DDoS and so is a bit of a scaling challenge in<br>
> large deployments.<br>
><br>
<br>
These are fully mitigated by caching.<br>
<br>
> There are probably plenty more I don't know since I'm not steeped in<br>
> operating OpenStack deployments.<br>
<br>
Thanks. I don't mean to combat the suggestions, but rather just see<br>
what it is exactly that makes us dislike the metadata service.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Mon, 20 Feb 2017 21:22:10 -0500<br>
From: Zhipeng Huang <<a href="mailto:zhipengh512@gmail.com">zhipengh512@gmail.com</a>><br>
To: user-committee <<a href="mailto:user-committee@lists.openstack.org">user-committee@lists.<wbr>openstack.org</a>>, OpenStack<br>
Operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: [Openstack-operators] [publiccloud-wg]Atlanta Virtual PTG<br>
agenda<br>
Message-ID:<br>
<CAHZqm+UMQFF8n==gET++c=<a href="mailto:9wfxGgHXkM64zLm6Oo2vvajqP6nQ@mail.gmail.com">9wfxGg<wbr>HXkM64zLm6Oo2vvajqP6nQ@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi team,<br>
<br>
Please find an initial draft of our virtual ptg on Thursday at<br>
<a href="https://etherpad.openstack.org/p/publiccloud-atlanta-ptg" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/publiccloud-atlanta-ptg</a> , feel free to add<br>
anything that you want to discuss<br>
<br>
--<br>
Zhipeng (Howard) Huang<br>
<br>
Standard Engineer<br>
IT Standard & Patent/IT Prooduct Line<br>
Huawei Technologies Co,. Ltd<br>
Email: <a href="mailto:huangzhipeng@huawei.com">huangzhipeng@huawei.com</a><br>
Office: Huawei Industrial Base, Longgang, Shenzhen<br>
<br>
(Previous)<br>
Research Assistant<br>
Mobile Ad-Hoc Network Lab, Calit2<br>
University of California, Irvine<br>
Email: <a href="mailto:zhipengh@uci.edu">zhipengh@uci.edu</a><br>
Office: Calit2 Building Room 2402<br>
<br>
OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-operators/attachments/20170220/5af73467/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-operators/<wbr>attachments/20170220/5af73467/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 21 Feb 2017 10:34:46 +0000<br>
From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
To: Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>><br>
Cc: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [nova] Metadata service over<br>
virtio-vsock<br>
Message-ID: <<a href="mailto:20170221103446.GA17041@redhat.com">20170221103446.GA17041@<wbr>redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On Mon, Feb 20, 2017 at 08:08:00PM +0000, Jeremy Stanley wrote:<br>
> On 2017-02-20 14:36:15 -0500 (-0500), Clint Byrum wrote:<br>
> > What exactly is the security concern of the metadata service? Perhaps<br>
> > those concerns can be addressed directly?<br>
> [...]<br>
><br>
> A few I'm aware of:<br>
><br>
> 1. It's something that runs in the control plane but needs to be<br>
> reachable from untrusted server instances (which may themselves even<br>
> want to be on completely non-routed networks).<br>
<br>
That is the key problem that virtio-vsock solves, by separating<br>
traffic out from the network stack there's no way for a guest<br>
to use vsock to access anything except services on the local<br>
compute host listening on vsock<br>
<br>
> 2. If you put a Web proxy between your server instances and the<br>
> metadata service and also make it reachable without going through<br>
> that proxy then instances may be able to spoof one another<br>
> (OSSN-0074).<br>
<br>
FYI, with virtio-vsock it is impossible for the guest to spoof<br>
the sending address of another guest. So the process on the host<br>
can use the socket peer address to reliably identify which guest<br>
it is communicating with. With the IP based metadata service<br>
you need to setup firewall rules on the host to drop traffic<br>
with spoofed source mac/ip address.<br>
<br>
> 3. Lots of things, for example facter, like to beat on it heavily<br>
> which makes for a fun DDoS and so is a bit of a scaling challenge in<br>
> large deployments.<br>
<br>
FYI, with virtio-vsock, you would need to either run the metdata<br>
service on every compute host, or have some kind of vhost<->tcp<br>
proxy on every compute host that forwards requests to the real<br>
metadata service off-host.<br>
<br>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/<wbr>dberrange/</a> :|<br>
|: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a> -o- <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~<wbr>danberr/</a> :|<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Tue, 21 Feb 2017 10:40:02 +0000<br>
From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
To: Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
Cc: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [nova] Metadata service over<br>
virtio-vsock<br>
Message-ID: <<a href="mailto:20170221104002.GB17041@redhat.com">20170221104002.GB17041@<wbr>redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On Mon, Feb 20, 2017 at 02:36:15PM -0500, Clint Byrum wrote:<br>
> What exactly is the security concern of the metadata service? Perhaps<br>
> those concerns can be addressed directly?<br>
><br>
> I ask because anything that requires special software on the guest is<br>
> a non-starter IMO. virtio is a Linux thing, so what does this do for<br>
> users of Windows? FreeBSD? etc.<br>
<br>
Red Hat is investing in creating virtio vsock drivers for Windows<br>
but I don't have an ETA for that yet. There's no work in *BSD in<br>
this area that I know of, but BSD does have support for virtio<br>
in general, so if virtio-vsock becomes used in any important<br>
places I would not be suprised if some BSD developers implemented<br>
vsock too.<br>
<br>
In any case, I don't think it neccessarily needs to be supported<br>
in every single possible scenario. The config drive provides the<br>
same data in a highly portable manner, albeit with the caveat<br>
about it being read-only. The use of metadata service (whether<br>
TCP or vsock based) is useful for cases needing the info from<br>
config drive to be dynamically updated - eg the role device<br>
tagging metadata. Only a very small subset of guests running on<br>
openstack actually use that data today. So it would not be the<br>
end of the world if some guests don't support vsock in the short<br>
to medium term - if the facility proves to be critically important<br>
to a wider range of guests that'll motivate developers of those<br>
OS to support it.<br>
<br>
<br>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/<wbr>dberrange/</a> :|<br>
|: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a> -o- <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~<wbr>danberr/</a> :|<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Tue, 21 Feb 2017 06:24:20 -0500<br>
From: Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
To: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [nova] Metadata service over<br>
virtio-vsock<br>
Message-ID: <<a href="mailto:1487676150-sup-3688@fewbar.com">1487676150-sup-3688@fewbar.<wbr>com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Excerpts from Daniel P. Berrange's message of 2017-02-21 10:40:02 +0000:<br>
> On Mon, Feb 20, 2017 at 02:36:15PM -0500, Clint Byrum wrote:<br>
> > What exactly is the security concern of the metadata service? Perhaps<br>
> > those concerns can be addressed directly?<br>
> ><br>
> > I ask because anything that requires special software on the guest is<br>
> > a non-starter IMO. virtio is a Linux thing, so what does this do for<br>
> > users of Windows? FreeBSD? etc.<br>
><br>
> Red Hat is investing in creating virtio vsock drivers for Windows<br>
> but I don't have an ETA for that yet. There's no work in *BSD in<br>
> this area that I know of, but BSD does have support for virtio<br>
> in general, so if virtio-vsock becomes used in any important<br>
> places I would not be suprised if some BSD developers implemented<br>
> vsock too.<br>
><br>
<br>
> In any case, I don't think it neccessarily needs to be supported<br>
> in every single possible scenario. The config drive provides the<br>
> same data in a highly portable manner, albeit with the caveat<br>
> about it being read-only. The use of metadata service (whether<br>
> TCP or vsock based) is useful for cases needing the info from<br>
> config drive to be dynamically updated - eg the role device<br>
> tagging metadata. Only a very small subset of guests running on<br>
> openstack actually use that data today. So it would not be the<br>
> end of the world if some guests don't support vsock in the short<br>
> to medium term - if the facility proves to be critically important<br>
> to a wider range of guests that'll motivate developers of those<br>
> OS to support it.<br>
><br>
<br>
Cool, so there's a chance it gets to near ubiquitous usability.<br>
<br>
However, I wonder, there's no need for performance here. Why not just<br>
make it a virtual USB drive that ejects and re-attaches on changes? That<br>
way you don't need Windows/BSD drivers.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br>
<br>
End of OpenStack-operators Digest, Vol 76, Issue 30<br>
******************************<wbr>*********************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Kind Regards<br> <br>Y. Rahulan <br></div>
</div>