Re: [openstack-dev] Request for comments for a possible solution

[Narasimhan, Vivekanandan]

Hi Mike,

Just one comment [Vivek]

-Original Message-
From: Mike Kolesnik [mailto:mkole...@redhat.com]
Sent: Sunday, December 21, 2014 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Robert Kukura
Subject: Re: [openstack-dev] [Neutron][L2Pop][HA Routers] Request for comments 
for a possible solution

Hi Mathieu,

Comments inline

Regards,
Mike

- Original Message -
> Mike,
>
> I'm not even sure that your solution works without being able to bind
> a router HA port to several hosts.
> What's happening currently is that you :
>
> 1.create the router on two l3agent.
> 2. those l3agent trigger the sync_router() on the l3plugin.
> 3. l3plugin.sync_routers() will trigger l2plugin.update_port(host=l3agent).
> 4. ML2 will bind the port to the host mentioned in the last update_port().
>
> From a l2pop perspective, this will result in creating only one tunnel
> to the host lastly specified.
> I can't find any code that forces that only the master router binds
> its router port. So we don't even know if the host which binds the
> router port is hosting the master router or the slave one, and so if
> l2pop is creating the tunnel to the master or to the slave.
>
> Can you confirm that the above sequence is correct? or am I missing
> something?

Are you referring to the alternative solution?

In that case it seems that you're correct so that there would need to be 
awareness of the master router at some level there as well.
I can't say for sure as I've been thinking on the proposed solution with no 
FDBs so there would be some issues with the alternative that need to be ironed 
out.

>
> Without the capacity to bind a port to several hosts, l2pop won't be
> able to create tunnel correctly, that's the reason why I was saying
> that a prerequisite for a smart solution would be to first fix the bug
> :
> https://bugs.launchpad.net/neutron/+bug/1367391
>
> DVR Had the same issue. Their workaround was to create a new
> port_binding tables, that manages the capacity for one DVR port to be
> bound to several host.
> As mentioned in the bug 1367391, this adding a technical debt in ML2,
> which has to be tackle down in priority from my POV.

I agree that this would simplify work but even without this bug fixed we can 
achieve either solution.

We have already knowledge of the agents hosting a router so this is completely 
doable without waiting for fix for bug 1367391.

Also from my understanding the bug 1367391 is targeted at DVR only, not at HA 
router ports.

[Vivek]  Currently yes, but Bob's concept embraces all replicated ports and so 
HA router ports will play into it :)

--
Thanks,

Vivek


>
>
> On Thu, Dec 18, 2014 at 6:28 PM, Mike Kolesnik  wrote:
> > Hi Mathieu,
> >
> > Thanks for the quick reply, some comments inline..
> >
> > Regards,
> > Mike
> >
> > - Original Message -
> >> Hi mike,
> >>
> >> thanks for working on this bug :
> >>
> >> On Thu, Dec 18, 2014 at 1:47 PM, Gary Kotton  wrote:
> >> >
> >> >
> >> > On 12/18/14, 2:06 PM, "Mike Kolesnik"  wrote:
> >> >
> >> >>Hi Neutron community members.
> >> >>
> >> >>I wanted to query the community about a proposal of how to fix HA
> >> >>routers not working with L2Population (bug 1365476[1]).
> >> >>This bug is important to fix especially if we want to have HA
> >> >>routers and DVR routers working together.
> >> >>
> >> >>[1] https://bugs.launchpad.net/neutron/+bug/1365476
> >> >>
> >> >>What's happening now?
> >> >>* HA routers use distributed ports, i.e. the port with the same
> >> >>IP & MAC
> >> >>  details is applied on all nodes where an L3 agent is hosting
> >> >>this router.
> >> >>* Currently, the port details have a binding pointing to an
> >> >>arbitrary node
> >> >>  and this is not updated.
> >> >>* L2pop takes this "potentially stale" information and uses it to
> >> >>create:
> >> >>  1. A tunnel to the node.
> >> >>  2. An FDB entry that directs traffic for that port to that node.
> >> >>  3. If ARP responder is on, ARP requests will not traverse the network.
> >> >>* Problem is, the master router wouldn't necessarily be running
> >> >>on the
> >> >>  reported agent.
> >> >>  This means that traffic would not reach the master node but
> >> >>some arbitrary
> >> >>  node where the router master might be running, but might be in
> >> >>another
> >> >>  state (standby, fail).
> >> >>
> >> >>What is proposed?
> >> >>Basically the idea is not to do L2Pop for HA router ports that
> >> >>reside on the tenant network.
> >> >>Instead, we would create a tunnel to each node hosting the HA
> >> >>router so that the normal learning switch functionality would
> >> >>take care of switching the traffic to the master router.
> >> >
> >> > In Neutron we just ensure that the MAC address is unique per network.
> >> > Could a duplicate MAC address cause problems here?
> >>
> >> gary, AFAIU, from a Neutron POV, there is only one port, which is
> >> the router Port, which is plugged twice. One time per port.
> >> I think 

Re: [openstack-dev] Request for comments for a possible solution

[Narasimhan, Vivekanandan]

Hi Mike,

Few clarifications inline [Vivek]

-Original Message-
From: Mike Kolesnik [mailto:mkole...@redhat.com]
Sent: Thursday, December 18, 2014 10:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L2Pop][HA Routers] Request for comments 
for a possible solution

Hi Mathieu,

Thanks for the quick reply, some comments inline..

Regards,
Mike

- Original Message -
> Hi mike,
>
> thanks for working on this bug :
>
> On Thu, Dec 18, 2014 at 1:47 PM, Gary Kotton  wrote:
> >
> >
> > On 12/18/14, 2:06 PM, "Mike Kolesnik"  wrote:
> >
> >>Hi Neutron community members.
> >>
> >>I wanted to query the community about a proposal of how to fix HA
> >>routers not working with L2Population (bug 1365476[1]).
> >>This bug is important to fix especially if we want to have HA
> >>routers and DVR routers working together.
> >>
> >>[1] https://bugs.launchpad.net/neutron/+bug/1365476
> >>
> >>What's happening now?
> >>* HA routers use distributed ports, i.e. the port with the same IP &
> >>MAC
> >>  details is applied on all nodes where an L3 agent is hosting this
> >>router.
> >>* Currently, the port details have a binding pointing to an
> >>arbitrary node
> >>  and this is not updated.
> >>* L2pop takes this "potentially stale" information and uses it to create:
> >>  1. A tunnel to the node.
> >>  2. An FDB entry that directs traffic for that port to that node.
> >>  3. If ARP responder is on, ARP requests will not traverse the network.
> >>* Problem is, the master router wouldn't necessarily be running on
> >>the
> >>  reported agent.
> >>  This means that traffic would not reach the master node but some
> >>arbitrary
> >>  node where the router master might be running, but might be in
> >>another
> >>  state (standby, fail).
> >>
> >>What is proposed?
> >>Basically the idea is not to do L2Pop for HA router ports that
> >>reside on the tenant network.
> >>Instead, we would create a tunnel to each node hosting the HA router
> >>so that the normal learning switch functionality would take care of
> >>switching the traffic to the master router.
> >
> > In Neutron we just ensure that the MAC address is unique per network.
> > Could a duplicate MAC address cause problems here?
>
> gary, AFAIU, from a Neutron POV, there is only one port, which is the
> router Port, which is plugged twice. One time per port.
> I think that the capacity to bind a port to several host is also a
> prerequisite for a clean solution here. This will be provided by
> patches to this bug :
> https://bugs.launchpad.net/neutron/+bug/1367391
>
>
> >>This way no matter where the master router is currently running, the
> >>data plane would know how to forward traffic to it.
> >>This solution requires changes on the controller only.
> >>
> >>What's to gain?
> >>* Data plane only solution, independent of the control plane.
> >>* Lowest failover time (same as HA routers today).
> >>* High backport potential:
> >>  * No APIs changed/added.
> >>  * No configuration changes.
> >>  * No DB changes.
> >>  * Changes localized to a single file and limited in scope.
> >>
> >>What's the alternative?
> >>An alternative solution would be to have the controller update the
> >>port binding on the single port so that the plain old L2Pop happens
> >>and notifies about the location of the master router.
> >>This basically negates all the benefits of the proposed solution,
> >>but is wider.
> >>This solution depends on the report-ha-router-master spec which is
> >>currently in the implementation phase.
> >>
> >>It's important to note that these two solutions don't collide and
> >>could be done independently. The one I'm proposing just makes more
> >>sense from an HA viewpoint because of it's benefits which fit the HA
> >>methodology of being fast & having as little outside dependency as
> >>possible.
> >>It could be done as an initial solution which solves the bug for
> >>mechanism drivers that support normal learning switch (OVS), and
> >>later kept as an optimization to the more general, controller based,
> >>solution which will solve the issue for any mechanism driver working
> >>with L2Pop (Linux Bridge, possibly others).
> >>
> >>Would love to hear your thoughts on the subject.
>
> You will have to clearly update the doc to mention that deployment
> with Linuxbridge+l2pop are not compatible with HA.

Yes this should be added and this is already the situation right now.
However if anyone would like to work on a LB fix (the general one or some 
specific one) I would gladly help with reviewing it.

>
> Moreover, this solution is downgrading the l2pop solution, by
> disabling the ARP-responder when VMs want to talk to a HA router.
> This means that ARP requests will be duplicated to every overlay
> tunnel to feed the OVS Mac learning table.
> This is something that we were trying to avoid with l2pop. But may be
> this is acceptable.

Yes basically you're correct, however this would be only limited to tho

Re: [openstack-dev] [neutron] L2 gateway as a service

[Narasimhan, Vivekanandan]

Hi Salvatore,



Thanks for the review comments on the BP.



Yes, Maruti’s BP supersedes the review https://review.openstack.org/#/c/100278 
posted by Isaku, and we

discussed with  Isaku during the summit to embrace his BP.



For the review https://review.openstack.org/#/c/93613 by Racha , we were not 
able to see how that

idea maps to implementation angle driven in Maruti’s BP.



And Kevin’s idea of giving neutron representation of external-attachment-points 
(good idea),  can be

used in the  implementation of Maruti’s BP  where in the attachment-points can 
be fed to ‘net-gateway-create’

command, instead of giving physical-network switch names/ports.



So we request Kevin , Racha and others, to peruse Maruti’s BP and post 
comments/questions

on the same, more specifically from the resource representation perspective 
(REST APIs and CLIs).



--

Thanks,



Vivek





From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Friday, November 14, 2014 10:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] L2 gateway as a service



Thanks guys.



I think you've answered my initial question. Probably not in the way I was 
hoping it to be answered, but it's ok.



So now we have potentially 4 different blueprint describing more or less 
overlapping use cases that we need to reconcile into one?

If the above is correct, then I suggest we go back to the use case and make an 
effort to abstract a bit from thinking about how those use cases should be 
implemented.



Salvatore



On 14 November 2014 15:42, Igor Cardoso 
mailto:igordc...@gmail.com>> wrote:

Hello all,

Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its 
use cases is exactly the L2 gateway. These proposals could probably be inserted 
in a more generic work for moving existing datacenter L2 resources to Neutron.

Cheers,



On 14 November 2014 15:28, Mathieu Rohon 
mailto:mathieu.ro...@gmail.com>> wrote:

Hi,

As far as I understood last friday afternoon dicussions during the
design summit, this use case is in the scope of another umbrella spec
which would define external connectivity for neutron networks. Details
of those connectivity would be defined through service plugin API.

Ian do you plan to define such an umbrella spec? or at least, could
you sum up the agreement of the design summit discussion in the ML?

I see at least 3 specs which would be under such an umbrella spec :
https://review.openstack.org/#/c/93329/ (BGPVPN)
https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN)
https://review.openstack.org/#/c/134179/ (l2 gw aas)



On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando 
mailto:sorla...@nicira.com>> wrote:
> Thanks Maruti,
>
> I have some comments and questions which I've posted on gerrit.
> There are two things I would like to discuss on the mailing list concerning
> this effort.
>
> 1) Is this spec replacing  https://review.openstack.org/#/c/100278 and
> https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds
> even more complexity.
>
> 2) It sounds like you should be able to implement this service plugin in
> either a feature branch or a repository distinct from neutron. Can you
> confirm that?
>
> Salvatore
>
> On 13 November 2014 13:26, Kamat, Maruti Haridas 
> mailto:maruti.ka...@hp.com>>
> wrote:
>>
>> Hi Friends,
>>
>>  As discussed during the summit, I have uploaded the spec for review
>> at https://review.openstack.org/#/c/134179/
>>
>> Thanks,
>> Maruti
>>
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev







--

Igor Duarte Cardoso.

http://igordcard.com

@igordcard


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] LeastNetwork scheduling for DHCP

[Narasimhan, Vivekanandan]

Hi Neutron Stackers,



There is an interest among vendors to bring Least Networks scheduling for DHCP 
into Openstack Neutron.



Currently there are the following blueprints lying there, all of them trying to 
address this issue:

https://review.openstack.org/111210

https://review.openstack.org/#/c/130912/

https://review.openstack.org/104587



We are trying  to pull together all these BPs as one Umbrella BP, on which we

can pour volunteers from every side, to clear out this BP itself as initial 
step.



So we would like to collaborate, to plan BP approval for these.



Please respond if you are interested.



--

Thanks,



Vivek





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

[Narasimhan, Vivekanandan]

Yes... If I recollect, we were using 1.10.x version during that time (wherein 
discovered this 
as output of ovsapp-ctl fdb-show). After that I didn’t get time to re-verify on 
later
versions of openvswitch.

BTW, if this is not intended behaviour, then I donot see any particular reason 
why VLANs
need not be enabled in the current DVR architecture.  

To enable dvr, I need to post a minor patch in L2 agent to bring-in 
DVR rules into Phys bridges (as VLANs are driven by phys bridges 
in OVS L2 Agent).

--
Thanks,

Vivek

-Original Message-
From: Kevin Benton [mailto:blak...@gmail.com] 
Sent: Thursday, September 18, 2014 12:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] DVR Tunnel Design Question

This sounds like a bug in Openvswitch. The unique constraint should be
VLAN+MAC instead of just VLAN, so observing the same MAC on a new VLAN
should just result in a new entry without the old one being ejected.

Without this behavior, it will also break transparent L2 firewalls.
For example (diagram below), if you divide a switch into two VLANs and then 
connect the sides together with a firewall in the middle that passes frames 
without modifying the MAC, the switch will see the same MAC on different VLANs. 
Based on the behavior you described, this wouldn't work. Is that correct?


-
|  x  x  x  x   |   x  x  x  x  |
|---|-
 VLAN 1 | |  VLAN2
  
  |   Firewall  |
  

On Wed, Sep 17, 2014 at 11:19 PM, Narasimhan, Vivekanandan 
 wrote:
> Hi Kevin,
>
>
>
> Typically we noticed that the underlay switches maintained a table 
> like
> this:
>
>
>
> VLAN IDMAC Address  Learned-Interface
>
>
>
> In the physical underlay, with the current architecture if we enable 
> VLAN, the same DVR Unique
>
> MAC will appear  on different VLANs as the packets get DVR Routed.
>
>
>
> This will result in the rows of the above tables in the switch to be 
> updated very frequently with new
>
> VLANs noted in incoming packets for the same DVR MAC Address, even 
> though they are from the
>
> same physical port.
>
>
>
> We are not sure if all the switches maintained the tables this way , 
> but atleast we
>
> saw Openvswitch implementations did.  So we consciously did not 
> promote VLANs for
>
> initial phase of DVR.
>
>
>
> --
>
> Thanks,
>
>
>
> Vivek
>
>
>
>
>
> From: Kevin Benton [mailto:blak...@gmail.com]
> Sent: Thursday, September 18, 2014 3:01 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] DVR Tunnel Design Question
>
>
>
> Can you clarify what you mean with the thrashing condition? MAC 
> addresses only need to be unique per-VLAN so I don't see how the same 
> MAC on multiple VLANs from the same physical port would lead to any issues.
>
>
>
> On Wed, Sep 17, 2014 at 12:41 PM, Armando M.  wrote:
>
> VLAN is on the radar, vxlan/gre was done to start with.
>
> I believe Vivek mentioned the rationale in some other thread. The gist 
> of it below:
>
> In the current architecture, we use a unique DVR MAC per compute node 
> to forward DVR Routed traffic directly to destination compute node.
> The DVR routed traffic from the source compute node will carry 
> 'destination VMs underlay VLAN' in the frame, but the Source Mac in 
> that same frame will be the DVR Unique MAC. So, same DVR Unique Mac is 
> used for potentially a number of overlay network VMs that would exist 
> on that same source compute node.
>
> The underlay infrastructure switches will see the same DVR Unique MAC 
> being associated with different VLANs on incoming frames, and so this 
> would result in VLAN Thrashing on the switches in the physical cloud 
> infrastructure. Since tunneling protocols carry the entire DVR routed 
> inner frames as tunnel payloads, there is no thrashing effect on 
> underlay switches.
>
> There will still be thrashing effect on endpoints on CNs themselves, 
> when they try to learn that association between inner frame source MAC 
> and the TEP port on which the tunneled frame is received. But that we 
> have addressed in L2 Agent by having a 'DVR Learning Blocker' table, 
> which ensures that learning for DVR routed packets alone is 
> side-stepped.
>
> As a result, VLAN was not promoted as a supported underlay for the 
> initial DVR architecture.
>
> Cheers,
> Armando
>
>
> On 16 September 2014 20:35, 龚永生  wrote:
>> I think the VLAN should also be supported later.  The tunnel should 
>> not be the prerequisite for the DVR feature.

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

[Narasimhan, Vivekanandan]

Hi Kevin,



Typically we noticed that the underlay switches maintained a table like this:



VLAN IDMAC Address  Learned-Interface



In the physical underlay, with the current architecture if we enable VLAN, the 
same DVR Unique

MAC will appear  on different VLANs as the packets get DVR Routed.



This will result in the rows of the above tables in the switch to be updated 
very frequently with new

VLANs noted in incoming packets for the same DVR MAC Address, even though they 
are from the

same physical port.



We are not sure if all the switches maintained the tables this way , but 
atleast we

saw Openvswitch implementations did.  So we consciously did not promote VLANs 
for

initial phase of DVR.



--

Thanks,



Vivek





From: Kevin Benton [mailto:blak...@gmail.com]
Sent: Thursday, September 18, 2014 3:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] DVR Tunnel Design Question



Can you clarify what you mean with the thrashing condition? MAC addresses only 
need to be unique per-VLAN so I don't see how the same MAC on multiple VLANs 
from the same physical port would lead to any issues.



On Wed, Sep 17, 2014 at 12:41 PM, Armando M. 
mailto:arma...@gmail.com>> wrote:

VLAN is on the radar, vxlan/gre was done to start with.

I believe Vivek mentioned the rationale in some other thread. The gist
of it below:

In the current architecture, we use a unique DVR MAC per compute node
to forward DVR Routed traffic directly to destination compute node.
The DVR routed traffic from the source compute node will carry
'destination VMs underlay VLAN' in the frame, but the Source Mac in
that same frame will be the DVR Unique MAC. So, same DVR Unique Mac is
used for potentially a number of overlay network VMs that would exist
on that same source compute node.

The underlay infrastructure switches will see the same DVR Unique MAC
being associated with different VLANs on incoming frames, and so this
would result in VLAN Thrashing on the switches in the physical cloud
infrastructure. Since tunneling protocols carry the entire DVR routed
inner frames as tunnel payloads, there is no thrashing effect on
underlay switches.

There will still be thrashing effect on endpoints on CNs themselves,
when they try to learn that association between inner frame source MAC
and the TEP port on which the tunneled frame is received. But that we
have addressed in L2 Agent by having a 'DVR Learning Blocker' table,
which ensures that learning for DVR routed packets alone is
side-stepped.

As a result, VLAN was not promoted as a supported underlay for the
initial DVR architecture.

Cheers,
Armando


On 16 September 2014 20:35, 龚永生 
mailto:gong...@unitedstack.com>> wrote:
> I think the VLAN should also be supported later.  The tunnel should not be
> the prerequisite for the DVR feature.
>
>
> -- Original --
> From:  "Steve Wormley"mailto:openst...@wormley.com>>;
> Date:  Wed, Sep 17, 2014 10:29 AM
> To:  
> "openstack-dev"mailto:openstack-dev@lists.openstack.org>>;
> Subject:  [openstack-dev] [neutron] DVR Tunnel Design Question
>
> In our environment using VXLAN/GRE would make it difficult to keep some of
> the features we currently offer our customers. So for a while now I've been
> looking at the DVR code, blueprints and Google drive docs and other than it
> being the way the code was written I can't find anything indicating why a
> Tunnel/Overlay network is required for DVR or what problem it was solving.
>
> Basically I'm just trying to see if I missed anything as I look into doing a
> VLAN/OVS implementation.
>
> Thanks,
> -Steve Wormley
>
>

> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev







--

Kevin Benton

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Tox run failure during installation of dependencies in requirements

[Narasimhan, Vivekanandan]

Hi Igor /Matthieu,



I am getting random connection timeouts to pypi.python.org with my machine 
behind the proxy when trying to run

Tox –e pep8

Dependency installation fails with the stack trace posted below.



However, similar issue does not occur when I use run_tests.sh to run the same 
set of tests.



My machine is able to reach pypi.python.org.  Some packages are getting 
installed while doing some others,

It fails as below.



It looks like am hitting the problem as here, but the solution proposed there 
isn’t working for me.

https://github.com/pypa/pip/issues/1805



--

Thanks,



Vivek





From: Igor Degtiarov [mailto:idegtia...@mirantis.com]
Sent: Wednesday, August 06, 2014 3:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Tox run failure during installation of 
dependencies in requirements



Hi,

Actually the same question, what is wrong with Tox now?




-- Igor



On Wed, Aug 6, 2014 at 1:19 PM, Narasimhan, Vivekanandan 
mailto:vivekanandan.narasim...@hp.com>> wrote:

Hi,



Recently , the Tox runs started to fail in my workspace.

It fails consistently during installing dependencies with the following.



Downloading/unpacking PrettyTable>=0.7,<0.8 (from 
python-keystoneclient>=0.10.0->-r 
/home/narasimv/dev/bug1350485/neutron/requirements.txt (line 22))

Cleaning up...

Exception:

Traceback (most recent call last):

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/basecommand.py",
 line 122, in main

status = self.run(options, args)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/commands/install.py",
 line 278, in run

requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, 
bundle=self.bundle)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/req.py",
 line 1197, in prepare_files

do_download,

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/req.py",
 line 1375, in unpack_url

self.session,

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/download.py",
 line 546, in unpack_http_url

resp = session.get(target_url, stream=True)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/_vendor/requests/sessions.py",
 line 468, in get

return self.request('GET', url, **kwargs)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/download.py",
 line 237, in request

return super(PipSession, self).request(method, url, *args, **kwargs)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/_vendor/requests/sessions.py",
 line 456, in request

resp = self.send(prep, **send_kwargs)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/_vendor/requests/sessions.py",
 line 559, in send

r = adapter.send(request, **kwargs)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/_vendor/requests/adapters.py",
 line 384, in send

raise Timeout(e, request=request)

Timeout: 
(, 'Connection to pypi.python.org<http://pypi.python.org> 
timed out. (connect timeout=15)')



The TOX was earlier running in the same workspace successfully on the machine

even though we were behind the proxy.



Could you please advise on how to resolve this problem?



--

Thanks,



Vivek




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Tox run failure during installation of dependencies in requirements

[Narasimhan, Vivekanandan]

Hi,



Recently , the Tox runs started to fail in my workspace.

It fails consistently during installing dependencies with the following.



Downloading/unpacking PrettyTable>=0.7,<0.8 (from 
python-keystoneclient>=0.10.0->-r 
/home/narasimv/dev/bug1350485/neutron/requirements.txt (line 22))

Cleaning up...

Exception:

Traceback (most recent call last):

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/basecommand.py",
 line 122, in main

status = self.run(options, args)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/commands/install.py",
 line 278, in run

requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, 
bundle=self.bundle)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/req.py",
 line 1197, in prepare_files

do_download,

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/req.py",
 line 1375, in unpack_url

self.session,

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/download.py",
 line 546, in unpack_http_url

resp = session.get(target_url, stream=True)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/_vendor/requests/sessions.py",
 line 468, in get

return self.request('GET', url, **kwargs)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/download.py",
 line 237, in request

return super(PipSession, self).request(method, url, *args, **kwargs)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/_vendor/requests/sessions.py",
 line 456, in request

resp = self.send(prep, **send_kwargs)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/_vendor/requests/sessions.py",
 line 559, in send

r = adapter.send(request, **kwargs)

  File 
"/home/narasimv/dev/bug1350485/neutron/.tox/pep8/local/lib/python2.7/site-packages/pip/_vendor/requests/adapters.py",
 line 384, in send

raise Timeout(e, request=request)

Timeout: 
(, 'Connection to pypi.python.org timed out. (connect 
timeout=15)')



The TOX was earlier running in the same workspace successfully on the machine

even though we were behind the proxy.



Could you please advise on how to resolve this problem?



--

Thanks,



Vivek



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] DVR and FWaaS integration

[Narasimhan, Vivekanandan]

Yi, since am from India, the FwaaS at 11PM  Wed is late for me.



Is it possible to have a meeting right after the l3 subteam meeting coming 
Thursday.

This evaluates to 10AM PST Thursday.



Swami, please let me know your availability as well.



--

Thanks,



Vivek





From: Yi Sun [mailto:beyo...@gmail.com]
Sent: Tuesday, July 08, 2014 9:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] DVR and FWaaS integration



Vivek,
I will try to join the DVR meeting. Since it conflicts with one of my other 
meeting (from my real job), I may join late or may not be able to join at all. 
If I missed it, please see if you can join FWaaS meeting at Wed 11:30AM PST  on 
openstack-meeting-3.  Otherwise, a separated meeting is still preferred

Thanks
Yi

On 7/4/14, 12:23 AM, Narasimhan, Vivekanandan wrote:

   Hi Yi,



   Swami will be available from this week.



   Will it be possible for you to join the regular DVR Meeting (Wed 8AM PST) 
next week and we can slot that to discuss this.



   I see that FwaaS is of much value for E/W traffic (which has challenges), 
but for me it looks easier to implement the same in N/S with the

   current DVR architecture, but there might be less takers on that.



   --

   Thanks,



   Vivek





   From: Yi Sun [mailto:beyo...@gmail.com]
   Sent: Thursday, July 03, 2014 11:50 AM
   To: 
openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
   Subject: Re: [openstack-dev] DVR and FWaaS integration



   The NS FW will be on a centralized node for sure. For the DVR + FWaaS 
solution is really for EW traffic. If you are interested on the topic, please 
propose your preferred meeting time and join the meeting so that we can discuss 
about it.

   Yi

   On 7/2/14, 7:05 PM, joehuang wrote:

  Hello,



  It’s hard to integrate DVR and FWaaS. My proposal is to split the FWaaS 
into two parts: one part is for east-west FWaaS, this part could be done on DVR 
side, and make it become distributed manner. The other part is for north-south 
part, this part could be done on Network Node side, that means work in central 
manner. After the split, north-south FWaaS could be implemented by software or 
hardware, meanwhile, east-west FWaaS is better to implemented by software with 
its distribution nature.



  Chaoyi Huang ( Joe Huang )

  OpenStack Solution Architect

  IT Product Line

  Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email: 
joehu...@huawei.com<mailto:joehu...@huawei.com>

  Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129, 
P.R.China



  发件人: Yi Sun [mailto:beyo...@gmail.com]
  发送时间: 2014年7月3日 4:42
  收件人: OpenStack Development Mailing List (not for usage questions)
  抄送: Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack Neutron)
  主题: Re: [openstack-dev] DVR and FWaaS integration



  All,

  After talk to Carl and FWaaS team , Both sides suggested to call a 
meeting to discuss about this topic in deeper detail. I heard that Swami is 
traveling this week. So I guess the earliest time we can have a meeting is 
sometime next week. I will be out of town on monday, so any day after Monday 
should work for me. We can do either IRC, google hang out, GMT or even a face 
to face.

  For anyone interested, please propose your preferred time.

  Thanks

  Yi



  On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin 
mailto:c...@ecbaldwin.net>> wrote:

  In line...

  On Jun 25, 2014 2:02 PM, "Yi Sun" 
mailto:beyo...@gmail.com>> wrote:
  >
  > All,
  > During last summit, we were talking about the integration issues 
between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. 
But after that meeting I was tight up with my work and did not get time to 
continue to follow up the issue. To not slow down the discussion, I'm 
forwarding out the email that I sent out as the follow up to the IRC meeting 
here, so that whoever may be interested on the topic can continue to discuss 
about it.
  >
  > First some background about the issue:
  > In the normal case, FW and router are running together inside the same 
box so that FW can get route and NAT information from the router component. And 
in order to have FW to function correctly, FW needs to see the both directions 
of the traffic.
  > DVR is designed in an asymmetric way that each DVR only sees one leg of 
the traffic. If we build FW on top of DVR, then FW functionality will be 
broken. We need to find a good method to have FW to work with DVR.
  >
  > ---forwarding email---
  >  During the IRC meeting, we think that we could force the traffic to 
the FW before DVR. Vivek had more detail; He thinks that since the br-int 
knowns whether a packet is routed or switched, it is possible for the br-int to 
forward traffic to FW before it f

Re: [openstack-dev] DVR and FWaaS integration

[Narasimhan, Vivekanandan]

Hi Yi,



Swami will be available from this week.



Will it be possible for you to join the regular DVR Meeting (Wed 8AM PST) next 
week and we can slot that to discuss this.



I see that FwaaS is of much value for E/W traffic (which has challenges), but 
for me it looks easier to implement the same in N/S with the

current DVR architecture, but there might be less takers on that.



--

Thanks,



Vivek





From: Yi Sun [mailto:beyo...@gmail.com]
Sent: Thursday, July 03, 2014 11:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] DVR and FWaaS integration



The NS FW will be on a centralized node for sure. For the DVR + FWaaS solution 
is really for EW traffic. If you are interested on the topic, please propose 
your preferred meeting time and join the meeting so that we can discuss about 
it.

Yi

On 7/2/14, 7:05 PM, joehuang wrote:

   Hello,



   It’s hard to integrate DVR and FWaaS. My proposal is to split the FWaaS into 
two parts: one part is for east-west FWaaS, this part could be done on DVR 
side, and make it become distributed manner. The other part is for north-south 
part, this part could be done on Network Node side, that means work in central 
manner. After the split, north-south FWaaS could be implemented by software or 
hardware, meanwhile, east-west FWaaS is better to implemented by software with 
its distribution nature.



   Chaoyi Huang ( Joe Huang )

   OpenStack Solution Architect

   IT Product Line

   Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email: 
joehu...@huawei.com

   Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129, P.R.China



   发件人: Yi Sun [mailto:beyo...@gmail.com]
   发送时间: 2014年7月3日 4:42
   收件人: OpenStack Development Mailing List (not for usage questions)
   抄送: Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack Neutron)
   主题: Re: [openstack-dev] DVR and FWaaS integration



   All,

   After talk to Carl and FWaaS team , Both sides suggested to call a meeting 
to discuss about this topic in deeper detail. I heard that Swami is traveling 
this week. So I guess the earliest time we can have a meeting is sometime next 
week. I will be out of town on monday, so any day after Monday should work for 
me. We can do either IRC, google hang out, GMT or even a face to face.

   For anyone interested, please propose your preferred time.

   Thanks

   Yi



   On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin 
mailto:c...@ecbaldwin.net>> wrote:

   In line...

   On Jun 25, 2014 2:02 PM, "Yi Sun" 
mailto:beyo...@gmail.com>> wrote:
   >
   > All,
   > During last summit, we were talking about the integration issues between 
DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after 
that meeting I was tight up with my work and did not get time to continue to 
follow up the issue. To not slow down the discussion, I'm forwarding out the 
email that I sent out as the follow up to the IRC meeting here, so that whoever 
may be interested on the topic can continue to discuss about it.
   >
   > First some background about the issue:
   > In the normal case, FW and router are running together inside the same box 
so that FW can get route and NAT information from the router component. And in 
order to have FW to function correctly, FW needs to see the both directions of 
the traffic.
   > DVR is designed in an asymmetric way that each DVR only sees one leg of 
the traffic. If we build FW on top of DVR, then FW functionality will be 
broken. We need to find a good method to have FW to work with DVR.
   >
   > ---forwarding email---
   >  During the IRC meeting, we think that we could force the traffic to the 
FW before DVR. Vivek had more detail; He thinks that since the br-int knowns 
whether a packet is routed or switched, it is possible for the br-int to 
forward traffic to FW before it forwards to DVR. The whole forwarding process 
can be operated as part of service-chain operation. And there could be a FWaaS 
driver that understands the DVR configuration to setup OVS flows on the br-int.

   I'm not sure what this solution would look like.  I'll have to get the 
details from Vivek.  It seems like this would effectively centralize the 
traffic that we worked so hard to decentralize.

   It did cause me to wonder about something:  would it be possible to reign 
the symmetry to the traffic by directing any response traffic back to the DVR 
component which handled the request traffic?  I guess this would require 
running conntrack on the target side to track and identify return traffic.  I'm 
not sure how this would be inserted into the data path yet.  This is a 
half-baked idea here.

   > The concern is that normally firewall and router are integrated together 
so that firewall can make right decision based on the routing result. But what 
we are suggesting is to split the firewall and router into two separated 
components, hence there could be issues. For example, FW will not be

Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture

[Narasimhan, Vivekanandan]

Managing the ports and plumbing logic is today driven by L2 Agent, with little 
assistance

from controller.



If we plan to move that functionality to the controller,  the controller has to 
be more

heavy weight (both hardware and software)  since it has to do the job of L2 
Agent for all

the compute servers in the cloud. , We need to re-verify all scale numbers for 
the controller

on POC’ing of such a change.



That said, replacing CLI with direct OVSDB calls in the L2 Agent is certainly a 
good direction.



Today, OVS Agent invokes flow calls of OVS-Lib but has no idea (or processing) 
to follow up

on success or failure of such invocations.  Nor there is certain guarantee that 
all such

flow invocations would be executed by the third-process fired by OVS-Lib to 
execute CLI.



When we transition to OVSDB calls which are more programmatic in nature, we can

enhance the Flow API (OVS-Lib) to provide more fine grained errors/return codes 
(or content)

and ovs-agent (and even other components) can act on such return state more

intelligently/appropriately.



--

Thanks,



Vivek





From: Armando M. [mailto:arma...@gmail.com]
Sent: Tuesday, June 17, 2014 10:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture



just a provocative thought: If we used the ovsdb connection instead, do we 
really need an L2 agent :P?



On 17 June 2014 18:38, Kyle Mestery 
mailto:mest...@noironetworks.com>> wrote:

Another area of improvement for the agent would be to move away from
executing CLIs for port commands and instead use OVSDB. Terry Wilson
and I talked about this, and re-writing ovs_lib to use an OVSDB
connection instead of the CLI methods would be a huge improvement
here. I'm not sure if Terry was going to move forward with this, but
I'd be in favor of this for Juno if he or someone else wants to move
in this direction.

Thanks,
Kyle


On Tue, Jun 17, 2014 at 11:24 AM, Salvatore Orlando 
mailto:sorla...@nicira.com>> wrote:
> We've started doing this in a slightly more reasonable way for icehouse.
> What we've done is:
> - remove unnecessary notification from the server
> - process all port-related events, either trigger via RPC or via monitor in
> one place
>
> Obviously there is always a lot of room for improvement, and I agree
> something along the lines of what Zang suggests would be more maintainable
> and ensure faster event processing as well as making it easier to have some
> form of reliability on event processing.
>
> I was considering doing something for the ovs-agent again in Juno, but since
> we've moving towards a unified agent, I think any new "big" ticket should
> address this effort.
>
> Salvatore
>
>
> On 17 June 2014 13:31, Zang MingJie 
> mailto:zealot0...@gmail.com>> wrote:
>>
>> Hi:
>>
>> Awesome! Currently we are suffering lots of bugs in ovs-agent, also
>> intent to rebuild a more stable flexible agent.
>>
>> Taking the experience of ovs-agent bugs, I think the concurrency
>> problem is also a very important problem, the agent gets lots of event
>> from different greenlets, the rpc, the ovs monitor or the main loop.
>> I'd suggest to serialize all event to a queue, then process events in
>> a dedicated thread. The thread check the events one by one ordered,
>> and resolve what has been changed, then apply the corresponding
>> changes. If there is any error occurred in the thread, discard the
>> current processing event, do a fresh start event, which reset
>> everything, then apply the correct settings.
>>
>> The threading model is so important and may prevent tons of bugs in
>> the future development, we should describe it clearly in the
>> architecture
>>
>>
>> On Wed, Jun 11, 2014 at 4:19 AM, Mohammad Banikazemi 
>> mailto:m...@us.ibm.com>>
>> wrote:
>> > Following the discussions in the ML2 subgroup weekly meetings, I have
>> > added
>> > more information on the etherpad [1] describing the proposed
>> > architecture
>> > for modular L2 agents. I have also posted some code fragments at [2]
>> > sketching the implementation of the proposed architecture. Please have a
>> > look when you get a chance and let us know if you have any comments.
>> >
>> > [1] https://etherpad.openstack.org/p/modular-l2-agent-outline
>> > [2] https://review.openstack.org/#/c/99187/
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

[Narasimhan, Vivekanandan]

Keshava,

Tunneled over to network node means:

OVS VXLAN Tunnel will be established between compute node and network node and 
packets will flow
through that OVS VXLAN Tunnel.

NAT'ing and tunneling are not related here.  NAT'ing happens in network node.  
Packets that need to
reach the external network will be tunneled to NN where SNAT'ing puts them onto 
external network.

--
Thanks,

Vivek

-Original Message-
From: A, Keshava
Sent: Friday, May 23, 2014 1:11 PM
To: OpenStack Development Mailing List (not for usage questions); Carl Baldwin
Cc: Narasimhan, Vivekanandan; Grover, Rajeev; A, Keshava
Subject: RE: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

Hi,
I have one basic question, what is this tunneled over to network node means ? 
(" At this point, the packet will go back out to br-int and but tunneled over 
to the network node just like any other intra-network traffic.")
What kind of tunnel between Compute to Network Node during SNAT ?
Why tunneling  will happen during NAT ?

Thanks & regards,
Keshava.A

-Original Message-
From: Carl Baldwin [mailto:c...@ecbaldwin.net]
Sent: Thursday, May 22, 2014 3:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

Hi,

I found this message in my backlog from when I was at the summit.
Sorry for the delay in responding.

The "default SNAT" or "dynamic SNAT" use case is one of the last details being 
worked in the DVR subteam.  That may be why you do not see any code around this 
in the patches that have been submitted.
Outbound traffic that will use this SNAT address will first enter the IR on the 
compute host.  In the IR, it will not match against any of the static SNAT 
addresses for floating IPs.  At that point the packet will be redirected to 
another port belonging to the central component of the DVR.  This port has an 
IP address  different from the default gateway address (e.g. 192.168.1.2 
instead of 192.168.1.1).  At this point, the packet will go back out to br-int 
and but tunneled over to the network node just like any other intra-network 
traffic.

Once the packet hits the central component of the DVR on the network node it 
will be processed very much like default SNAT traffic is processed in the 
current Neutron implementation.  Another "interconnect subnet" should not be 
needed here and would be overkill.

I hope this helps.  Let me know if you have any questions.

Carl

On Fri, May 16, 2014 at 1:57 AM, Wuhongning  wrote:
> Hi DVRers,
>
> I didn't see any detail documents or source code on how to deal with
> routing packet from DVR node to SNAT gw node. If the routing table see
> a outside ip, it should be matched with a default route, so for the
> next hop, which interface will it select?
>
> Maybe another standalone "interconnect subnet" per DVR is needed,
> which connect each DVR node and optionally, the SNAT gw node. For
> packets from dvr
> node->snat node, the interconnect subnet act as the "default route"
> node->for this
> host, and the next hop will be the snat node.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

[Narasimhan, Vivekanandan]

Thanks Carl, for pitching in for us.

As Carl said, this is the last detail that is being worked out.

Wuhogning,

I am requesting Rajeev and Mike(CC'ed) who are working in DVR SNAT
to post the document into to the blueprint link here, so that you
can take a look.

https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr

-
Thanks,

Vivek



-Original Message-
From: Carl Baldwin [mailto:c...@ecbaldwin.net]
Sent: Friday, May 23, 2014 3:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

Hi,

I found this message in my backlog from when I was at the summit.
Sorry for the delay in responding.

The "default SNAT" or "dynamic SNAT" use case is one of the last
details being worked in the DVR subteam.  That may be why you do not
see any code around this in the patches that have been submitted.
Outbound traffic that will use this SNAT address will first enter the
IR on the compute host.  In the IR, it will not match against any of
the static SNAT addresses for floating IPs.  At that point the packet
will be redirected to another port belonging to the central component
of the DVR.  This port has an IP address  different from the default
gateway address (e.g. 192.168.1.2 instead of 192.168.1.1).  At this
point, the packet will go back out to br-int and but tunneled over to
the network node just like any other intra-network traffic.

Once the packet hits the central component of the DVR on the network
node it will be processed very much like default SNAT traffic is
processed in the current Neutron implementation.  Another
"interconnect subnet" should not be needed here and would be overkill.

I hope this helps.  Let me know if you have any questions.

Carl

On Fri, May 16, 2014 at 1:57 AM, Wuhongning  wrote:
> Hi DVRers,
>
> I didn't see any detail documents or source code on how to deal with routing
> packet from DVR node to SNAT gw node. If the routing table see a outside ip,
> it should be matched with a default route, so for the next hop, which
> interface will it select?
>
> Maybe another standalone "interconnect subnet" per DVR is needed, which
> connect each DVR node and optionally, the SNAT gw node. For packets from dvr
> node->snat node, the interconnect subnet act as the "default route" for this
> host, and the next hop will be the snat node.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Is vendor CI tests pass mandatory to merging fixes upstream...

[Narasimhan, Vivekanandan]

Hi  Neutron'ers,



Could you please let us know if all vendor CI tests must pass , If we need to 
merge a fix to

the upstream master?



For example , for this bug fix https://review.openstack.org/#/c/93624/

Posted to upstream master for merge,  we see failure for Mellanox CI and 
Hyper-V CI.



The UT failures don't seem to relate to our fix, but it would be helpful for us 
to touch base

with Mellanox CI and Hyper-V CI wwners to go forward and get these failures 
resolved.



Could someone you link us to them?



--

Thanks,



Vivek











___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Security Groups] Pings to router ip from VM with default security groups

[Narasimhan, Vivekanandan]

Hi ,



We have been trying to understand behavior of security group rules in icehouse 
stable.



The default security group contains 4 rules, two ingress and two egress.



The two ingress rules are one for IPv4 and other for IPv6.

We see both the ingress rules use cyclic security groups, wherein the rule 
contains remote_security_group_id

the same as the security_group_id itself.



Vm1 <-à  R1 ß> Vm2



Vm1 20.0.0.2

R1 interface 1 - 20.0.0.1

R1 interface 2 - 30.0.0.1

Vm2 30.0.0.2



We saw that with default security groups, Vm1 can ping its DHCP Server IP 
because of provider_rule in security group rules.



Vm1 is also able to ping Vm2 via router R1, as Vm1 port and Vm2 port share the 
same security group.



However, we noticed that a Vm1 is also able to ping the router interfaces (R1 
interface 1 ip - 20.0.0.1) and also ping router

interface (R1 interface 2 IP - 30.0.0.1)  successfully.



Router interfaces donot have security groups associated with them, so the 
router interface IPs won' t get added to

the IPTables of the CN where the Vm1 resides.



We are not able to figure how the ping from the Vm1 to the router interfaces 
work when

no explicit rules are added to allow them.



Could you please throw some light on this?



--

Thanks,



Vivek



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ML2] L2 population mechanism driver

[Narasimhan, Vivekanandan]

Hi Slawek,

I think L2 pop driver needs to be used in conjunction with other mechanism 
drivers.

It only deals with pro-actively informing agents on which MAC Addresses became
available/unavailable on cloud nodes and is not meant for binding/unbinding 
ports
on segments.

If you configure mechanism_drivers=openvswitch,l2population in your 
ml2_conf.ini and restart
your neutron-server, you'll notice that bind_port is handled by OVS mechanism 
driver
(via AgentMechanismDriverBase inside ml2/drivers/mech_agent.py).

--
Thanks,

Vivek


-Original Message-
From: Sławek Kapłoński [mailto:sla...@kaplonski.pl]
Sent: Sunday, May 04, 2014 12:32 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [ML2] L2 population mechanism driver

Hello,

Last time I want to try using L2pop mechanism driver in ML2 (and openvswitch
agents on compute nodes). But every time when I try to spawn instance I have
got error "binding failed". After some searching in code I found that l2pop
driver have not implemented method "bind_port" and as it inherit directly from
"MechanismDriver" this method is in fact not implemented.
Is is ok and this mechanism driver should be used in other way or maybe there
is some bug in this driver and it miss this method?

Best regards
Slawek Kaplonski
sla...@kaplonski.pl

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Unit test test_ovs_neutron_agent fails with dependency errors

[Narasimhan, Vivekanandan]

Hi,



I 've been trying to run test_ovs_neutron_agent.py unit test from openstack 
neutron master 'tip', and

am hitting  dependency errors for novaclient as here:



Do we need to clone python-novaclient repo as well and point PYTHONPATH to it 
and

try re-running the same?



Please help.



==

ERROR: 
neutron.tests.unit.openvswitch.test_ovs_neutron_agent.TestOvsNeutronAgent.test_tunnel_update

--

Empty attachments:

  pythonlogging:''

  pythonlogging:'neutron.api.extensions'



Traceback (most recent call last):

  File "neutron/tests/unit/openvswitch/test_ovs_neutron_agent.py", line 89, in 
setUp

notifier_cls = notifier_p.start()

  File "/usr/local/lib/python2.7/dist-packages/mock-1.0.1-py2.7.egg/mock.py", 
line 1396, in start

result = self.__enter__()

  File "/usr/local/lib/python2.7/dist-packages/mock-1.0.1-py2.7.egg/mock.py", 
line 1252, in __enter__

self.target = self.getter()

  File "/usr/local/lib/python2.7/dist-packages/mock-1.0.1-py2.7.egg/mock.py", 
line 1414, in 

getter = lambda: _importer(target)

  File "/usr/local/lib/python2.7/dist-packages/mock-1.0.1-py2.7.egg/mock.py", 
line 1102, in _importer

thing = _dot_lookup(thing, comp, import_path)

  File "/usr/local/lib/python2.7/dist-packages/mock-1.0.1-py2.7.egg/mock.py", 
line 1091, in _dot_lookup

__import__(import_path)

  File "neutron/plugins/openvswitch/ovs_neutron_plugin.py", line 29, in 

   from neutron.db import agents_db

  File "neutron/db/agents_db.py", line 24, in 

from neutron.extensions import agent as ext_agent

  File "neutron/extensions/agent.py", line 20, in 

from neutron.api.v2 import base

  File "neutron/api/v2/base.py", line 30, in 

from neutron.notifiers import nova

  File "neutron/notifiers/nova.py", line 19, in 

from novaclient.v1_1.contrib import server_external_events

ImportError: cannot import name server_external_events

==

ERROR: 
neutron.tests.unit.openvswitch.test_ovs_neutron_agent.TestOvsNeutronAgent.test_update_ports_returns_changed_vlan

--

Empty attachments:

  pythonlogging:''

  pythonlogging:'neutron.api.extensions'



Traceback (most recent call last):

  File "neutron/tests/unit/openvswitch/test_ovs_neutron_agent.py", line 89, in 
setUp

notifier_cls = notifier_p.start()

  File "/usr/local/lib/python2.7/dist-packages/mock-1.0.1-py2.7.egg/mock.py", 
line 1396, in start

result = self.__enter__()

  File "/usr/local/lib/python2.7/dist-packages/mock-1.0.1-py2.7.egg/mock.py", 
line 1252, in __enter__

self.target = self.getter()

  File "/usr/local/lib/python2.7/dist-packages/mock-1.0.1-py2.7.egg/mock.py", 
line 1414, in 

getter = lambda: _importer(target)

  File "/usr/local/lib/python2.7/dist-packages/mock-1.0.1-py2.7.egg/mock.py", 
line 1102, in _importer

thing = _dot_lookup(thing, comp, import_path)

  File "/usr/local/lib/python2.7/dist-packages/mock-1.0.1-py2.7.egg/mock.py", 
line 1091, in _dot_lookup

__import__(import_path)

  File "neutron/plugins/openvswitch/ovs_neutron_plugin.py", line 29, in 

   from neutron.db import agents_db

  File "neutron/db/agents_db.py", line 24, in 

from neutron.extensions import agent as ext_agent

  File "neutron/extensions/agent.py", line 20, in 

from neutron.api.v2 import base

  File "neutron/api/v2/base.py", line 30, in 

from neutron.notifiers import nova

  File "neutron/notifiers/nova.py", line 19, in 

from novaclient.v1_1.contrib import server_external_events

ImportError: cannot import name server_external_events



Ran 52 tests in 0.239s

FAILED (failures=46)



--

Thanks,



Vivek



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev