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