[Openstack-operators] OpenStack-operators Digest, Vol 76, Issue 30
Y.Rahulan
rahulan.y at gmail.com
Wed Feb 22 06:14:14 UTC 2017
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-request at lists.openstack.org> wrote:
> Send OpenStack-operators mailing list submissions to
> openstack-operators at 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-request at lists.openstack.org
>
> You can reach the person managing the list at
> openstack-operators-owner at 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 <volenbovsky at yandex.ru>
> To: Anwar Durrani <durrani.anwar at gmail.com>
> Cc: openstack-operators <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] Instances are not creating after
> adding 3 additional nova nodes
> Message-ID: <04649DC8-CA9A-4EED-BC64-26BD02948F22 at 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.anwar at 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 <mrhillsman at gmail.com
> <mailto:mrhillsman at 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 <zioproto at gmail.com
> <mailto:zioproto at 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.anwar at gmail.com
> <mailto:durrani.anwar at gmail.com>>:
> > >
> > > On Thu, Feb 16, 2017 at 1:44 PM, Saverio Proto <zioproto at gmail.com
> <mailto:zioproto at 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 at 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
> >
> > mrhillsman at gmail.com <mailto:mrhillsman at 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 at 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 <kevin at benton.pub>
> To: Kostyantyn Volenbovskyi <volenbovsky at yandex.ru>
> Cc: openstack-operators <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] Instances are not creating after
> adding 3 additional nova nodes
> Message-ID:
> <CAO_F6JMFSadCJx2isjZEBuSyPEAdzAi4t5pf7fTH74422jpXqg at 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 <
> volenbovsky at 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.anwar at 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 <mrhillsman at 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 <zioproto at 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.anwar at gmail.com>:
> >>> >
> >>> > On Thu, Feb 16, 2017 at 1:44 PM, Saverio Proto <zioproto at 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 at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-operators
> >>>
> >>
> >>
> >>
> >> --
> >> Kind regards,
> >>
> >> Melvin Hillsman
> >> Ops Technical Lead
> >> OpenStack Innovation Center
> >>
> >> mrhillsman at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at 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 <major at mhtx.net>
> To: openstack-operators at lists.openstack.org
> Subject: [Openstack-operators] [osops][osops-tools-monitoring] Updates
> for monitoring plugins
> Message-ID: <1263d686-af4a-b72a-2bca-188dbe525e62 at 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 <alifshit at redhat.com>
> To: openstack-operators at lists.openstack.org
> Subject: [Openstack-operators] [nova] Metadata service over
> virtio-vsock
> Message-ID:
> <CACqyMieod-E7XpdaKsr9RwqvB9dGGa5irRnNn4CC
> gEyDeszD9w at 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 <clint at fewbar.com>
> To: openstack-operators <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] [nova] Metadata service over
> virtio-vsock
> Message-ID: <1487619171-sup-3470 at 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 <fungi at yuggoth.org>
> To: openstack-operators <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] [nova] Metadata service over
> virtio-vsock
> Message-ID: <20170220200800.GB12827 at 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 <clint at fewbar.com>
> To: openstack-operators <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] [nova] Metadata service over
> virtio-vsock
> Message-ID: <1487624452-sup-6552 at 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 <zhipengh512 at gmail.com>
> To: user-committee <user-committee at lists.openstack.org>, OpenStack
> Operators <openstack-operators at lists.openstack.org>
> Subject: [Openstack-operators] [publiccloud-wg]Atlanta Virtual PTG
> agenda
> Message-ID:
> <CAHZqm+UMQFF8n==gET++c=9wfxGgHXkM64zLm6Oo2vvajqP6nQ at 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: huangzhipeng at huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipengh at 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" <berrange at redhat.com>
> To: Jeremy Stanley <fungi at yuggoth.org>
> Cc: openstack-operators <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] [nova] Metadata service over
> virtio-vsock
> Message-ID: <20170221103446.GA17041 at 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" <berrange at redhat.com>
> To: Clint Byrum <clint at fewbar.com>
> Cc: openstack-operators <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] [nova] Metadata service over
> virtio-vsock
> Message-ID: <20170221104002.GB17041 at 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 <clint at fewbar.com>
> To: openstack-operators <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] [nova] Metadata service over
> virtio-vsock
> Message-ID: <1487676150-sup-3688 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170222/76d577a0/attachment-0001.html>
More information about the OpenStack-operators
mailing list