Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Wuhongning]

Does it make sense to move all advanced extension out of ML2, like security 
group, qos...? Then we can just talk about advanced service itself, without 
bothering basic neutron object (network/subnet/port)

Traditionally, SG is applied in CN, and FWaas is applied in NN (bound to L3 
agent), however in DVR they are bluing, for each host has a L3 agent, this 
brings opportunity to move all service related features out of L2 agent, and 
coordinate  the two security modules (SG  FW for W-E traffic). However, 
neutron agents (l2/l3/advanced service) needs some rework.

When all these service features is detached from ML2, we can easily keep the 
mainstream OVS continually as L2 backend, and vendor specific hardware as the 
service policy enforcement backend such as acl/qos for high performance.

So maybe a trade-off is better: an optionally new policy service plugin 
together with SG and FWaas, cloud operate can choose what to present to 
enduser, but without concept of EP/EPG/BD/RD(now renamed to L2Pand L3P), Policy 
only focus on service layer, and policy template will be applied to existing 
neutron port object.

EP/EPG/L2P/L3P is really not so friendly to endusers facing. I asked some SMB 
IT staff and personal user of amazon AWS (they all have very limited networking 
knowledge), they can easily understand port/network/subnet, but can't 
understand those GBP objects. So, maybe apply advanced service policy to 
existing basic neutron object is more smoothly for endusers to accept.


From: Kevin Benton [blak...@gmail.com]
Sent: Friday, August 08, 2014 2:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way 
forward


Can you link to the etherpad you mentioned?

In the mean time, apologies for another analogy in
advance. :-)

If I give you an API to sort a list, I'm free to implement it however I want as 
long as I return a sorted list. However, there is no way me to know based on a 
call to this API that you might only be looking for the second largest element, 
so it won't be the most efficient approach because I will always have to sort 
the entire list.
If I give you a higher level API to declare that you want elements of a list 
that match a criteria in a certain order, then the API can make the 
optimization to not actually sort the whole list if you just need the first of 
the largest two elements.

The former is analogous to the security groups API, and the latter to the GBP 
API.

On Aug 7, 2014 4:00 PM, Aaron Rosen 
aaronoro...@gmail.commailto:aaronoro...@gmail.com wrote:



On Thu, Aug 7, 2014 at 12:08 PM, Kevin Benton 
blak...@gmail.commailto:blak...@gmail.com wrote:
I mean't 'side stepping' why GBP allows for the comment you made previous, 
With the latter, a mapping driver could determine that communication between 
these two hosts can be prevented by using an ACL on a router or a switch, 
which doesn't violate the user's intent and buys a performance improvement and 
works with ports that don't support security groups..

Neutron's current API is a logical abstraction and enforcement can be done 
however one chooses to implement it. I'm really trying to understand at the 
network level why GBP allows for these optimizations and performance 
improvements you talked about.

You absolutely cannot enforce security groups on a firewall/router that sits at 
the boundary between networks. If you try, you are lying to the end-user 
because it's not enforced at the port level. The current neutron APIs force you 
to decide where things like that are implemented.

The current neutron API's are just logical abstractions. Where and how things 
are actually enforced are 100% an implementation detail of a vendors system.  
Anyways, moving the discussion to the etherpad...

The higher level abstractions give you the freedom to move the enforcement by 
allowing the expression of broad connectivity requirements.
Why are you bringing up logging connections?

This was brought up as a feature proposal to FWaaS because this is a basic 
firewall feature missing from OpenStack. However, this does not preclude a 
FWaaS vendor from logging.

Personally, I think one could easily write up a very short document probably 
less than one page with examples showing/exampling how the current neutron API 
works even without a much networking background.

The difficulty of the API for establishing basic connectivity isn't really the 
problem. It's when you have to compose a bunch of requirements and make sure 
nothing is violating auditing and connectivity constraints that it becomes a 
problem. We are arguing about the levels of abstraction. You could also write 
up a short document explaining to novice programmers how to use C to read and 
write database entries to an sqlite database, but that doesn't mean it's the 
best level of abstraction for what the users are trying to accomplish.

I'll let 

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Wuhongning]

Thanks for your reply, Stefano. 
Indeed general balancing issue are much more important than this special GBP 
case, and I'll stay tuned for your result.

However, what I want to touch here is another kind of balancing: how to 
introduce a huge feature(like GBP) into openstack, especially it already has 
its own resource model with some overlapping semantically? Even GBP code and 
API is stable enough and could be merged someday, this issue wouldn't disappear.

We may choose to push the whole big monolithic feature into one place, or 
decouple it into different layers, and merge each to corresponding layer: low 
level atomic layer like nova/neutron/cinder, and abstract level orchestration 
layer like heat/congress)


From: Stefano Maffulli [stef...@openstack.org]
Sent: Thursday, August 14, 2014 7:18 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way 
forward

On 08/12/2014 06:46 PM, Wuhongning wrote:
 I couldn't have been at the IRC meeting for the time difference, are
 there any conclusion for this topic, or is it still open?

I, the PTL, some core reviewers and many in the GBP team are actively
working on a proposal to send to the list for quick evaluation. Stay tuned.


 I've tried
 to collect main concerns from previous posts (if something is lost or
 mistaken, just let me know):

 Concern 1 [...] Concern 6 [...]

These are some of the concerns I saw, too. There are other, once you
start looking at this discussion as one touching the larger issue of how
we can, as a community, strike an acceptable balance between shipping
quality code while adding features, keeping the fast innovation pace.

 Is it an option to split the GBP into core and extension, to easily
 meet all those concerns?
[...]

I think these are all valid suggestions and they are in similar forms on
the table at the moment as options.

The solution we're looking for is not something that is limited to GBP
but a wider fix (or at least a reasonable attempt) to the balancing act
I mentioned above: new features vs 'stable' code. Expect a proposal soon.

/stef


--
Ask and answer questions on https://ask.openstack.org

___
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] Simple proposal for stabilizing new features in-tree

[Wuhongning]

FWaas can't seamlessly work with DVR yet. A BP [1] has been submitted, but it 
can only handle NS traffic, leaving W-E untouched. If we implement the WE 
firewall in DVR, the iptable might be applied at a per port basis, so there are 
some overlapping with SG (Can we image a packet run into iptable hook twice 
between VM and the wire, for both ingress and egress directions?).

Maybe the overall service plugins (including service extension in ML2) needs 
some cleaning up, It seems that Neutron is just built from separate single 
blocks.

[1]  
http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/neutron-dvr-fwaas.rst


From: Sridar Kandaswamy (skandasw) [skand...@cisco.com]
Sent: Thursday, August 14, 2014 3:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new 
features in-tree


Hi Aaron:


There is a certain fear of another cascading chain of emails so with hesitation 
i send this email out. :-)


1) I could not agree with u more on the issue with the logs and the pain with 
debugging issues here. Yes for sure bugs do keep popping up but often times, 
(speaking for fwaas) - given the L3 agent interactions - there are a multitude 
of reasons for a failure. An L3Agent crash or a router issue - also manifests 
itself as an fwaas issue - i think ur first paste is along those lines (perhaps 
i could be wrong without much context here).


The L3Agent - service coexistence is far from ideal - but this experience has 
lead to two proposals - a vendor proposal [1] that actually tries to address 
such agent limitations and collaboration on another community proposal[2] to 
enable the L3 Agent to be more suited to hosting services. Hopefully [2] will 
get picked up in K and should help provide the necessary infrastructure to 
clean up the reference implementation.


2) Regarding ur point on the  FWaaS API - the intent of the feature by design 
was to keep the service abstraction separate from how it is inserted in the 
network - to keep this vendor/technology neutral. The first priority, post 
Havana was to address  service insertion to get away from the all routers model 
[3] but did not get the blessings needed. Now with a redrafted proposal for 
Juno[4] again an effort is being made to address this now for the second time 
in the 2 releases post H.


In general, I would make a request that before we decide to go ahead and start 
moving things out into an incubator area - more discussion is needed.  We don’t 
want  to land up in a situation in K-3 where we find out that this model does 
not quite work for whatever reason. Also i wonder about the hoops to get out 
from incubation. As vendors who try to align with the community and upstream 
our work - we don’t want to land up waiting more cycles - there is quite a bit 
of frustration that is felt here too.


Lets also think about the impacts on feature velocity, somehow that keeps 
popping into my head every time i buy a book from a certain online retailer. :-)


[1] https://review.openstack.org/#/c/90729/

[2] https://review.openstack.org/#/c/91532/

[3] https://review.openstack.org/#/c/62599/

[4] https://review.openstack.org/#/c/93128/


Thanks


Sridar


From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 13, 2014 at 3:56 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new 
features in-tree

Hi,

I've been thinking a good bit on this on the right way to move forward with 
this and in general the right way new services should be added. Yesterday I was 
working on a bug that was causing some problems in the openstack infra. We 
tracked down the issue then I uploaded a patch for it. A little while later 
after jenkins voted back a -1 so I started looking through the logs to see what 
the source of the failure was (which was actually unrelated to my patch). The 
random failure in the fwaas/vpn/l3-agent code which all outputs to the same log 
file that contains many traces for every run even successful ones. In one skim 
of this log file I was able to spot 4 [1]bugs which shows  these new 
experimental services that we've added to neutron have underlying problems 
(even though they've been in the tree for 2 releases+ now). This puts a huge 
strain on the whole openstack development community as they are always recheck 
no bug'ing due to neutron failures.

If you look at the fwaas work that was done. This merged over two releases ago 
and still does not have a complete API as there is no concept of where 
enforcement should be done. Today, enforcement is done across all of a tenant's 
routers making it more or less useless imho and we're just carrying it along in 
the tree 

Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree

[Wuhongning]

Hi Sridar,

Yes I know this is only for phase 1, while I'm also thinking about how it 
should be in next phase. At least, zone concept should be introduced, we may 
use it to replace SG, to eliminate potential conflicts of defining ACL in two 
different places.


From: Sridar Kandaswamy (skandasw) [skand...@cisco.com]
Sent: Thursday, August 14, 2014 10:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new 
features in-tree

Hi Wuhongning:

Yes u are correct – this is phase 1 to at least get basic perimeter firewall 
support working with DVR before looking for an optimal way to address E – W 
traffic.

Thanks

Sridar

From: Wuhongning wuhongn...@huawei.commailto:wuhongn...@huawei.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, August 14, 2014 at 1:05 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new 
features in-tree

FWaas can't seamlessly work with DVR yet. A BP [1] has been submitted, but it 
can only handle NS traffic, leaving W-E untouched. If we implement the WE 
firewall in DVR, the iptable might be applied at a per port basis, so there are 
some overlapping with SG (Can we image a packet run into iptable hook twice 
between VM and the wire, for both ingress and egress directions?).

Maybe the overall service plugins (including service extension in ML2) needs 
some cleaning up, It seems that Neutron is just built from separate single 
blocks.

[1]  
http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/neutron-dvr-fwaas.rst

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

Re: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator

[Wuhongning]

+1 to service plugin

It's better to strip service related extensions from ML2 core plugin as 
possible as we can, and put them in separate service plugin. Not only QOS, but 
also SG or possible other extensions. For the binding issue, vif-detail dict 
might be used for foreign key association.

Whenever service is added, new key type could be defined in vif-detail dict to 
associate with service object uuid from this new plugin. Vendors can even 
implement their own private extension without any change to ML2 by defining 
their customized vif-detail fields. Not only port, but network/subnet should 
also add such meta dict fields in their attribute, flexible foreign key support 
has been in absence for a long time on these ML2 core resource.

In the previous GBP discussion, I've also suggested similar idea. If we have 
clean boundary between ML2 core plugin and service plugin, the argumentative 
EP/EPG or renamed PT/PG resource object could be eliminated even if GBP is in 
the Neutron, because we can apply service contract group objects directly onto 
existing port/network/subnet resource by foreign key association binding, 
without reinvent these overlapped concept.


From: Salvatore Orlando [sorla...@nicira.com]
Sent: Wednesday, August 20, 2014 6:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][QoS] Request to be considered for 
neutron-incubator

In the current approach QoS support is being hardwired into ML2.

Maybe this is not the best way of doing that, as perhaps it will end up 
requiring every mech driver which enforces VIF configuration should support it.
I see two routes. One is a mechanism driver similar to l2-pop, and then you 
might have a look at the proposed extension framework (and partecipate into the 
discussion).
The other is doing a service plugin. Still, we'll have to solve how to 
implement the binding between a port/network and the QoS entity. If we go for 
the approach we've chosen so far the resource extension model you still have to 
deal with ML2 extensions. But I like orthogonality in services, and QoS is a 
service to me.
Another arguable point is that we might want to reconsider our abuse^H^H^H^H^H 
use of resource attribute extension, but this is a story for a different thread.

Regarding the incubator request, I think we need to wait for the process to be 
blessed. But you have my support and I would happy to help to assist with 
this work item through its process towards graduation.

This obviously provided the QoS team wants me to do that!

Salvatore


On 19 August 2014 23:15, Alan Kavanagh 
alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com wrote:
+1, I am hoping this is just a short term holding point and this will 
eventually be merged into main branch as this is a feature a lot of companies, 
us included would definitely benefit from having supported and many thanks to 
Sean for sticking with this and continue to push this.
/Alan

-Original Message-
From: Collins, Sean 
[mailto:sean_colli...@cable.comcast.commailto:sean_colli...@cable.comcast.com]
Sent: August-19-14 8:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][QoS] Request to be considered for 
neutron-incubator

Hi,

The QoS API extension has lived in Gerrit/been in review for about a year. It's 
gone through revisions, summit design sessions, and for a little while, a 
subteam.

I would like to request incubation in the upcoming incubator, so that the code 
will have a more permanent home where we can collaborate and improve.
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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][QoS] Request to be considered for neutron-incubator

[Wuhongning]

Absolutely it's not a good idea to encourage vendor implementing their own 
attributes in vif-detail, and I just mean it is *possible* to do this, which 
make sense when some feature is wanted temporarily before it is approved by 
community. As for the conflicts, restriction can be made that certain prefix 
must be attached: _private_vendorA_xxx.

For the vif-detail dumping ground, I'm not sure if API compatibility needs it. 
For example now the security group uuid is applied on the PORT object, and this 
api call is sent to ML2 plugin for association. If we change the api style, let 
PORT uuid be applied on SG object then indeed no foreign key is needed.


From: Kevin Benton [blak...@gmail.com]
Sent: Wednesday, August 20, 2014 2:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][QoS] Request to be considered for 
neutron-incubator

Vendors can even implement their own private extension without any change to 
ML2 by defining their customized vif-detail fields.

I'm not sure this is a good thing. What happens when 3 different vendors all 
implement the same attribute with the same name with different behavior? Since 
the API is no longer standard even with the reference core plugin, it fragments 
the clients. Each vendor will need to write it's own neutron client changes, 
GUIs, etc.

If the ML2 vif-details structure is going to become a dumping ground for 
anything, why even store things there in the first place? Since everything will 
require custom clients, the port ID can just be used as a foreign key to 
another API instead and the ML2 objects don't need to change at all.


On Tue, Aug 19, 2014 at 6:11 PM, Wuhongning 
wuhongn...@huawei.commailto:wuhongn...@huawei.com wrote:
+1 to service plugin

It's better to strip service related extensions from ML2 core plugin as 
possible as we can, and put them in separate service plugin. Not only QOS, but 
also SG or possible other extensions. For the binding issue, vif-detail dict 
might be used for foreign key association.

Whenever service is added, new key type could be defined in vif-detail dict to 
associate with service object uuid from this new plugin. Vendors can even 
implement their own private extension without any change to ML2 by defining 
their customized vif-detail fields. Not only port, but network/subnet should 
also add such meta dict fields in their attribute, flexible foreign key support 
has been in absence for a long time on these ML2 core resource.

In the previous GBP discussion, I've also suggested similar idea. If we have 
clean boundary between ML2 core plugin and service plugin, the argumentative 
EP/EPG or renamed PT/PG resource object could be eliminated even if GBP is in 
the Neutron, because we can apply service contract group objects directly onto 
existing port/network/subnet resource by foreign key association binding, 
without reinvent these overlapped concept.


From: Salvatore Orlando [sorla...@nicira.commailto:sorla...@nicira.com]
Sent: Wednesday, August 20, 2014 6:12 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][QoS] Request to be considered for 
neutron-incubator

In the current approach QoS support is being hardwired into ML2.

Maybe this is not the best way of doing that, as perhaps it will end up 
requiring every mech driver which enforces VIF configuration should support it.
I see two routes. One is a mechanism driver similar to l2-pop, and then you 
might have a look at the proposed extension framework (and partecipate into the 
discussion).
The other is doing a service plugin. Still, we'll have to solve how to 
implement the binding between a port/network and the QoS entity. If we go for 
the approach we've chosen so far the resource extension model you still have to 
deal with ML2 extensions. But I like orthogonality in services, and QoS is a 
service to me.
Another arguable point is that we might want to reconsider our abuse^H^H^H^H^H 
use of resource attribute extension, but this is a story for a different thread.

Regarding the incubator request, I think we need to wait for the process to be 
blessed. But you have my support and I would happy to help to assist with 
this work item through its process towards graduation.

This obviously provided the QoS team wants me to do that!

Salvatore


On 19 August 2014 23:15, Alan Kavanagh 
alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com wrote:
+1, I am hoping this is just a short term holding point and this will 
eventually be merged into main branch as this is a feature a lot of companies, 
us included would definitely benefit from having supported and many thanks to 
Sean for sticking with this and continue to push this.
/Alan

-Original Message-
From: Collins, Sean 
[mailto:sean_colli...@cable.comcast.commailto:sean_colli...@cable.comcast.com]
Sent: August-19-14 8:33

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

[Wuhongning]

It would satisfy everyone if horizon support all APIs, either in tree or in the 
lab, but at the perquisite that we have enough resource for horizon.

Else for the limitation of resource, we have to sort by the priority, then 
should we focus on APIs being baked in the incubator first?


From: Kevin Benton [blak...@gmail.com]
Sent: Tuesday, September 02, 2014 9:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Incubator concerns from packaging 
perspective

Is it possible to have a /contrib folder or something similar where 
experimental modules can be placed? Requiring a separate Horizon distribution 
for every project in the incubator is really going to make it difficult to get 
users to try them out.


On Mon, Sep 1, 2014 at 6:39 PM, joehuang 
joehu...@huawei.commailto:joehu...@huawei.com wrote:
Hello,

1. As dashboard, Horizon even does not support all stable OpenStack API ( 
including Neutron API ), not mention to unstable API
2. For incubation feature, the introduced API is not stable and not necessary 
for Horizon to support that.
3. The incubation feature could be experience by CLI/python client, but not in 
general delivery Horizon distribution.
4. If some customer asked the vendor to provide Horizon support for the 
incubation feature, the vendor can do the Horizon customization case by case, 
but no relationship with the general distribution of Horizon.

Is the logical above reasonable?

Best Regards

Chaoyi Huang ( Joe Huang )

-邮件原件-
发件人: Robert Kukura 
[mailto:kuk...@noironetworks.commailto:kuk...@noironetworks.com]
发送时间: 2014年9月1日 22:37
收件人: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

Sure, Horizon (or Heat) support is not always required for new features 
entering incubation, but when a goal in incubating a feature is to get it 
packaged with OpenStack distributions and into the hands of as many early 
adopters as possible to gather feedback, these integrations are very important.

-Bob

On 9/1/14, 9:05 AM, joehuang wrote:
 Hello,

 Not all features which had already been shipped in Neutron supported by 
 Horizon. For example, multi provider network.

 This is not the special case only happened in Neutron. For example, Glance 
 delivered V2 api in IceHouse or even early and support Image muti-locations 
 feature, but this feature also not available from Horizon.

 Fortunately, the CLI/python client can give us the opportunity to use this 
 powerful feature.

 So, It's not necessary to link Neutron incubation with Horizon tightly. The 
 feature implemented in Horizon can be introduced when the the incubation 
 graduate.

 Best regards.

 Chaoyi Huang ( joehuang )

 
 发件人: Maru Newby [ma...@redhat.commailto:ma...@redhat.com]
 发送时间: 2014年9月1日 17:53
 收件人: OpenStack Development Mailing List (not for usage questions)
 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging 
 perspective

 On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) 
 pkila...@cisco.commailto:pkila...@cisco.com wrote:


 On 8/26/14, 4:49 AM, Maru Newby 
 ma...@redhat.commailto:ma...@redhat.com wrote:

 On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi)
 pkila...@cisco.commailto:pkila...@cisco.com wrote:


 On 8/23/14, 5:36 PM, Maru Newby 
 ma...@redhat.commailto:ma...@redhat.com wrote:

 On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam
 sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com
 wrote:

 On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery
 mest...@mestery.commailto:mest...@mestery.com
 wrote:
 On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka
 ihrac...@redhat.commailto:ihrac...@redhat.com
 wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 20/08/14 18:28, Salvatore Orlando wrote:
 Some comments inline.

 Salvatore

 On 20 August 2014 17:38, Ihar Hrachyshka 
 ihrac...@redhat.commailto:ihrac...@redhat.com
 mailto:ihrac...@redhat.commailto:ihrac...@redhat.com wrote:

 Hi all,

 I've read the proposal for incubator as described at [1], and
 I have several comments/concerns/suggestions to this.

 Overall, the idea of giving some space for experimentation
 that does not alienate parts of community from Neutron is
 good. In that way, we may relax review rules and quicken
 turnaround for preview features without loosing control on those 
 features too much.

 Though the way it's to be implemented leaves several concerns,
 as
 follows:

 1. From packaging perspective, having a separate repository
 and tarballs seems not optimal. As a packager, I would better
 deal with a single tarball instead of two. Meaning, it would
 be better to keep the code in the same tree.

 I know that we're afraid of shipping the code for which some
 users may expect the usual level of support and stability and
 compatibility. This can be solved by making it explicit 

Re: [openstack-dev] [Neutron] DVR SNAT shortcut

[Wuhongning]

From: Zang MingJie [zealot0...@gmail.com]
Sent: Thursday, June 26, 2014 6:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut

On Wed, Jun 25, 2014 at 10:29 PM, McCann, Jack jack.mcc...@hp.com wrote:
  If every compute node is
  assigned a public ip, is it technically able to improve SNAT packets
  w/o going through the network node ?

 It is technically possible to implement default SNAT at the compute node.

 One approach would be to use a single IP address per compute node as a
 default SNAT address shared by all VMs on that compute node.  While this
 optimizes for number of external IPs consumed per compute node, the downside
 is having VMs from different tenants sharing the same default SNAT IP address
 and conntrack table.  That downside may be acceptable for some deployments,
 but it is not acceptable in others.

 To resolve the problem, we are using double-SNAT,

 first, set up one namespace for each router, SNAT tenant ip ranges to
 a separate range, say 169.254.255.0/24

 then, SNAT from 169.254.255.0/24 to public network.

 We are already using this method, and saved tons of ips in our
 deployment, only one public ip is required per router agent

Functionally it could works, but break the existing normal OAM pattern, which 
expecting VMs from one tenant share a public IP, but share no IP with other 
tenant. As I know, at least some customer don't accept this way, they think VMs 
in different hosts appear as different public IP is very strange.

In fact I severely doubt the value of N-S distributing in a real commercialized 
production environment, including FIP. There are many things that traditional 
N-S central nodes need to control: security, auditing, logging, and so on, it 
is not the simple forwarding. We need a tradeoff between performance and policy 
control model:

1. N-S traffic is usually much less than W-E traffic, do we really need 
distribute N-S traffic besides W-E traffic?
2. With NFV progress like intel DPDK, we can build very cost-effective service 
application on commodity x86 server (simple SNAT with 10Gbps/s per core at 
average Internet packet length)



 Another approach would be to use a single IP address per router per compute
 node.  This avoids the multi-tenant issue mentioned above, at the cost of
 consuming more IP addresses, potentially one default SNAT IP address for each
 VM on the compute server (which is the case when every VM on the compute node
 is from a different tenant and/or using a different router).  At that point
 you might as well give each VM a floating IP.

 Hence the approach taken with the initial DVR implementation is to keep
 default SNAT as a centralized service.

 - Jack

 -Original Message-
 From: Zang MingJie [mailto:zealot0...@gmail.com]
 Sent: Wednesday, June 25, 2014 6:34 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut

 On Wed, Jun 25, 2014 at 5:42 PM, Yongsheng Gong gong...@unitedstack.com 
 wrote:
  Hi,
  for each compute node to have SNAT to Internet, I think we have the
  drawbacks:
  1. SNAT is done in router, so each router will have to consume one public 
  IP
  on each compute node, which is money.

 SNAT can save more ips than wasted on floating ips

  2. for each compute node to go out to Internet, the compute node will have
  one more NIC, which connect to physical switch, which is money too
 

 Floating ip also need a public NIC on br-ex. Also we can use a
 separate vlan to handle the network, so this is not a problem

  So personally, I like the design:
   floating IPs and 1:N SNAT still use current network nodes, which will have
  HA solution enabled and we can have many l3 agents to host routers. but
  normal east/west traffic across compute nodes can use DVR.

 BTW, does HA implementation still active ? I haven't seen it has been
 touched for a while

 
  yong sheng gong
 
 
  On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie zealot0...@gmail.com wrote:
 
  Hi:
 
  In current DVR design, SNAT is north/south direction, but packets have
  to go west/east through the network node. If every compute node is
  assigned a public ip, is it technically able to improve SNAT packets
  w/o going through the network node ?
 
  SNAT versus floating ips, can save tons of public ips, in trade of
  introducing a single failure point, and limiting the bandwidth of the
  network node. If the SNAT performance problem can be solved, I'll
  encourage people to use SNAT over floating ips. unless the VM is
  serving a public service
 
  --
  Zang MingJie
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  

Re: [openstack-dev] DVR and FWaaS integration

[Wuhongning]

From: Carl Baldwin [c...@ecbaldwin.net]
Sent: Monday, June 30, 2014 3:43 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] DVR and FWaaS integration

On Mon, Jun 30, 2014 at 3:43 AM, Carl Baldwin 
c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote:

In line...

On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.commailto: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 able to 
 get enough information to setup zone. Normally Zone contains a group of 
 interfaces that can be used in the firewall policy to enforce the direction 
 of the policy. If we forward traffic to firewall before DVR, then we can only 
 create policy based on subnets not the interface.
 Also, I’m not sure if we have ever planed to support SNAT on the DVR, but if 
 we do, then it depends on at which point we forward traffic to the FW, the 
 subnet may not even work for us anymore (even DNAT could have problem too).

I agree that splitting the firewall from routing presents some problems that 
may be difficult to overcome.  I don't know how it would be done while 
maintaining the benefits of DVR.

Another half-baked idea:  could multi-primary state replication be used between 
DVR components to enable firewall operation?  Maybe work on the HA router 
blueprint -- which is long overdue to be merged Btw -- could be leveraged.  The 
number of DVR pieces could easily far exceed that of active firewall 
components normally used in such a configuration so there could be a major 
scaling problem.  I'm really just thinking out loud here.

Maybe you (or others) have other ideas?

I think ovs based firewall may resolve the conflict between distributed and 
stateful. Redirect response traffic from ovs to iptable will bring a lot of 
challenge, such as how to restore source mac when traffic return to br-int from 
iptable.


In the future, security group and fwaas should be merged, present to user a 
unified firewall API.



 --- end of forwarding 

 YI


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto: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][ML2] Support dpdk ovs with ml2 plugin

[Wuhongning]

hi,

It's a very important use case for multiple vswitchs. Now we use a fork version 
of ovs-dpdk to support NFV service chaining deployment, however all other 
traffic are still in the kernel ovs path, including management and storage 
traffic, and it will be very difficult to switch all these traffic to userspace 
ovs.

there is no problem for two ovs instance, they works very well. we have two 
vswitched daemon, none of original ovs userspace tools are never touched, but 
userspace-ovs-vswitchd(also with some little patch) is re-compiled without 
kernel datapath. we separate the ovsdb instance, and have all userspace ovs 
vsctl  ofctl point to another communication target.

then we patched ML2 plugin with new vnicvif type, also with a new 
user-ovs-agent deployed on each CN.
we didn't mix the ovs and user-ovs (user-ovs is positioned as high performance, 
so a dedicated VF is assigned to it). but if you want to create a segment 
across ovs and user-ovs, just connect user-ovs to br-eth through it's kni veth 
interface.

hope helpful for this discussion.



From: Czesnowicz, Przemyslaw [przemyslaw.czesnow...@intel.com]
Sent: Wednesday, July 16, 2014 9:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2 plugin

I don't think this is a usecase that could be supported right now.
There will be multiple issues with running two ovs instances on the node, e.g. 
how to  manage two sets of userspace utilities, two ovsdb servers etc.
Also there would be some limitations from how ml2 plugin does port  binding 
(different segmentation ids would have to be used for the two ovs instances)

This could be done if ovs was able to run two datapaths at the same time 
(kernel and dpdk enabled userspace datapath).
I would like to concentrate on the more simple usecase where some nodes are 
optimized for high perf  net i/o

Thanks
Przemek

-Original Message-
From: Mathieu Rohon [mailto:mathieu.ro...@gmail.com]
Sent: Friday, July 11, 2014 10:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2 plugin

A simple usecase could be to have a compute node able start VM with optimized 
net I/O or standard net I/O, depending on the network flavor ordered for this 
VM.

On Fri, Jul 11, 2014 at 11:16 AM, Czesnowicz, Przemyslaw 
przemyslaw.czesnow...@intel.com wrote:


 Can you explain whats the use case for  running both ovs and userspace
 ovs on the same host?



 Thanks

 Przemek

 From: loy wolfe [mailto:loywo...@gmail.com]
 Sent: Friday, July 11, 2014 3:17 AM


 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2
 plugin



 +1



 It's totally different between ovs and userspace ovs.

 also, there is strong need to keep ovs even we have a userspace ovs in
 the same host





 --


 Intel Shannon Limited
 Registered in Ireland
 Registered Office: Collinstown Industrial Park, Leixlip, County
 Kildare Registered Number: 308263 Business address: Dromore House,
 East Park, Shannon, Co. Clare

 This e-mail and any attachments may contain confidential material for
 the sole use of the intended recipient(s). Any review or distribution
 by others is strictly prohibited. If you are not the intended
 recipient, please contact the sender and delete all copies.


 ___
 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
--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.



___
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][DVR]: Will DVR support external gateway with snat disabled?

[Wuhongning]

Now in L3 API, we can create a router with external gateway, while enable_snat 
setting to false.
Now in DVR code, all cenral NS processing is related with snat, so does it 
still support NS central gw without snat?

Also, is it possible to separate the scheduling of NS central gateway and 
SNAT(or other central service)? This will make sense if we want to have linux 
router as the NS gw to terminate all internal traffic, but leave all L4 
service(NAT/FW/VPN/LB) to some hardware device.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Wuhongning]

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

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

[Wuhongning]

sorry it's very strange that I can't receive any mail with [neutron] tag, but 
[nova] is ok. So I just find reply thread from archives.

So, will this additional port and vxlan tunnel be the same concept I've 
mentioned as interconnect network? It should works, but bring another 
question: if CN has no vxlan provider network configed in neutron.conf(only 
vlan provider is used), will it mean that I can't use DVR snat?

Also, another gw ip is occupied, it seems a little strange for user.

Here is another idea: can we let the central NN snat use DVR logical mac? Then 
we can config each CN router's next hop to NN snat out from the device where it 
received packet, with next hop ip can also be the gw interface ip(no need for 
second ip), if we delete all gw interface ip from all DVR router's local table.

I've done test in sles sp2, and it works!

=

Vivek,
CN to NN Vxlan tunnel is something user/customer configured ?
Or DVR is mandating this VxLan tunnel to reach from NN from CN ?
Means the packets are encapsulated over network even they are not mandated to 
do so ?

Then there should be standard if something is getting done like this.


Thanks  regards,
Keshava.A

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

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:carl at 
ecbaldwin.nethttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev]
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 wuhongning at 
huawei.comhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
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

Re: [openstack-dev] [Neutron] Enabling vlan trunking on neutron port.

[Wuhongning]

Internal vlan is not necessarily obstacle to vlan trunk, no qinq support in ovs 
is the key factor.

If ovs suppport qinq, vlan trunk could be treated as a generalized flat type 
network, which let packets from tenant VM go to the wire unmodified, if packets 
carry no tag, then it's the same as current flat type.



From: YAMAMOTO Takashi [yamam...@valinux.co.jp]
Sent: Wednesday, September 24, 2014 11:08 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Enabling vlan trunking onneutron 
port.

more specifically, the way OVS-agent uses OVS (internal vlan) is
incompatible with tenant tagged VLANs.
ofagent for Juno, which also uses OVS as its dataplane, doesn't have
the problem.
i'm not sure how tenant VLANs are supposed to be used with neutron,
though.  (eg. what ip addresses should be used for non-trunk VLANs)

YAMAMOTO Takashi

 Aaron: untrue.  It does, but OVS doesn't, and so networks implemented with
 the OVS driver will drop packets.  Use Linuxbridge instead.
 --
 Ian.

 On 19 September 2014 22:27, Aaron Rosen aaronoro...@gmail.com wrote:

 Neutron doesn't allow you to send tagged traffic from the guest today
 https://github.com/openstack/neutron/blob/master/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py#L384


 On Fri, Sep 19, 2014 at 7:01 AM, Parikshit Manur 
 parikshit.ma...@citrix.com wrote:

  Hi All,

 I have a setup which has VM on flat provider network ,
 and I want to reach VM on VLAN provider network. The packets are forwarded
 till veth pair and are getting dropped by br-int.



 Can neutron port be configured to allow vlan  trunking?



 Thanks,

 Parikshit Manur

 ___
 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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] what happened to ModularL2Agent?

[Wuhongning]

Hi,

In the Juno cycle there is proposal of ModularL2Agent [1,2], which is very 
useful to develop agent for new backend with much less redundant code. Without 
that, we have to either fork a new agent by copying large amount of existing 
l2agent code, or patch existing l2agent. However in the K pad [3] it seems that 
this feature disappeared?

Now there are some interest on hybrid backend (e.g. Hierachical Binding), and 
some BPs are proposed to patch OVS agent. But it has two drawbacks: 1) tightly 
coupled with OVS; 2) OVS agent became unnecessarily heavier. With ML2agent we 
only need to add separated driver modules in the common L2agent framework, but 
not to patch the monolithic ovs agent.

Also if it is convenient  to write only modules but not the whole agent, 
backend providers may prefer to move out most of the logic from MD to agent 
side driver, for better stability for Neutron controller node and easier 
co-existing with other backend. Ofagent shows good compatibility of l2pop to 
build vxlan/gre tunnel network between itself and other ovs/linuxbridge agent.

Or are there any general consideration about Neutron agent side consolidation, 
either L2/L3/L4-7？

1. https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions
2. https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
3. https://etherpad.openstack.org/p/kilo-neutron-summit-topics

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

Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate

[Wuhongning]

+1, the hint should be persistent as other server instance metadata.


From: Alex Xu [sou...@gmail.com]
Sent: Wednesday, October 29, 2014 9:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Add scheduler-hints when 
migration/rebuild/evacuate



2014-10-29 13:42 GMT+08:00 Chen CH Ji 
jiche...@cn.ibm.commailto:jiche...@cn.ibm.com:

Yes, I remember that spec might talk about local storage (in local db?) and it 
can be the root cause

And I think we need persistent storage otherwise the scheduler hints can't 
survive in some conditions such as system reboot or upgrade ?


Yeah, that's problem. And I have talk with Jay Lau, look like there already got 
agreement on persistent it.


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: 
jiche...@cn.ibm.commailto:jiche...@cn.ibm.com
Phone: +86-10-82454158tel:%2B86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, 
Beijing 100193, PRC

[Inactive hide details for Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 
12:37, Chen CH Ji wrote: ]Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 
12:37, Chen CH Ji wrote: 

From: Alex Xu x...@linux.vnet.ibm.commailto:x...@linux.vnet.ibm.com
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: 10/29/2014 01:34 PM
Subject: Re: [openstack-dev] [Nova] Add scheduler-hints when 
migration/rebuild/evacuate





On 2014年10月29日 12:37, Chen CH Ji wrote:

I think we already support to specify the host when doing evacuate and 
migration ?

Yes, we support to specify the host, but schedule-hints is different thing.


if we need use hints that passed from creating instance, that means we need to 
persistent schedule hints
I remember we used to have a spec for store it locally ...


I also remember we have one spec for persistent before, but I don't know why it 
didn't continue.
And I think maybe we needn't persistent schedule-hints, just add pass new 
schedule-hints when
migration the instance. Nova just need provide the mechanism.


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: 
jiche...@cn.ibm.commailto:jiche...@cn.ibm.com
Phone: +86-10-82454158tel:%2B86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, 
Beijing 100193, PRC

[Inactive hide details for Alex Xu ---10/29/2014 12:19:35   PM---Hi, 
Currently migration/rebuild/evacuate didn't support   pass]Alex Xu 
---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't 
support pass

From: Alex Xu x...@linux.vnet.ibm.commailto:x...@linux.vnet.ibm.com
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: 10/29/2014 12:19 PM
Subject: [openstack-dev] [Nova] Add scheduler-hints when 
migration/rebuild/evacuate





Hi,

Currently migration/rebuild/evacuate didn't support pass
scheduler-hints, that means any migration
can't use schedule-hints that passed when creating instance.

Can we add scheduler-hints support when migration/rebuild/evacuate? That
also can enable user
move in/out instance to/from an server group.

Thanks
Alex


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




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

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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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] [all] [tc] Multi-clouds integration by OpenStack cascading

[Wuhongning]

Hi keshava,

Thanks for interested in Cascading. Here are some very simple explanation:

Basically Datacenter is not in the 2-level tree of cascading. We use term POD 
to represent a cascaded child openstack (same meaning of your term Zone?). 
There may be single or multiple PODs in one Datacenter, Just like below:

(A, B, C)  ...  (D, E)  ...  (F)  ...   (G)
Each character represent a POD or child openstack, while parenthesis represent 
a Datacenter. 

Each POD has a corresponding virtual host node in the parent openstack, so when 
scheduler of any projects (nova/neutron/cinder...) locate a host node, the 
resource POD is determined, also with its geo-located Datacenter by side 
effect. Cascading don't schedule by Datacenter directly, DC is just an 
attribute of POD (for example we can configure host aggregate to identify a DC 
with multiple PODs). The upper scale of POD is fixed, maybe several hundreds, 
so a super large DC with tens of thousands servers could be built by 
modularized PODs, avoiding the difficult of tuning and maintaining such a huge 
monolithic openstack.

Next do you mean networking reachability? Sorry for the limitation of mail post 
I can just give some very simple idea: in parent openstack the L2pop and DVR is 
used, so L2/L3 agent-proxy in each virtual host node can get all the vm 
reachability information of other POD, then they are set to local POD by 
Neutron REST API. However, cascading depends on some feature not exists yet in 
current Neutron, like L2GW, pluggable external network, WE Fwaas in DVR, 
centralized FIP in DVR... so we have to do some little patch in the front. In 
the future if these features is merged, these patch code can be removed. 

Indeed Neutron is the most challenge part of cascading, without considering 
those proxies in the parent openstack virtual host node, Neutron patchs account 
for 85% or more LOC in the whole project.

Regards,
Wu

From: keshava [keshav...@hp.com]
Sent: Wednesday, October 29, 2014 2:22 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
OpenStack cascading

This is very interesting problem to solve.
I am curious to know how the reachability is provided across different
Datacenter.
How to know which VM is part of which Datacenter?
VM may be in different Zone but under same DC or in different DC itself.

How this problem is solved?


thanks  regards,
keshava



--
View this message in context: 
http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html
Sent from the Developer mailing list archive at Nabble.com.

___
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] [nfv] VM-based VLAN trunking blueprints

[Wuhongning]

Is the trunk port use case like the super vlan?

Also there is another typical use case maybe not covered: extended flat 
network. Traffic on the port carries multiple vlans, but these vlans are not 
necessarily managed by neutron-network, so can not be classified to trunk port. 
And they don't need a gateway to communicate with other nodes in the physical 
provider network, what they expect neutron to do, is much like what the flat 
network does(so I call it extended flat): just keep the packets as is 
bidirectionally between wire and vnic.


From: Erik Moe [erik@ericsson.com]
Sent: Tuesday, November 04, 2014 5:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints


I created an etherpad and added use cases (so far just the ones in your email).

https://etherpad.openstack.org/p/tenant_vlans

/Erik


From: Erik Moe [mailto:erik@ericsson.com]
Sent: den 2 november 2014 23:12
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints



From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: den 31 oktober 2014 23:35
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints


On 31 October 2014 06:29, Erik Moe 
erik@ericsson.commailto:erik@ericsson.com wrote:


I thought Monday network meeting agreed on that “VLAN aware VMs”, Trunk network 
+ L2GW were different use cases.

Still I get the feeling that the proposals are put up against each other.

I think we agreed they were different, or at least the light was beginning to 
dawn on the differences, but Maru's point was that if we really want to decide 
what specs we have we need to show use cases not just for each spec 
independently, but also include use cases where e.g. two specs are required and 
the third doesn't help, so as to show that *all* of them are needed.  In fact, 
I suggest that first we do that - here - and then we meet up one lunchtime and 
attack the specs in etherpad before submitting them.  In theory we could have 
them reviewed and approved by the end of the week.  (This theory may not be 
very realistic, but it's good to set lofty goals, my manager tells me.)
Ok, let’s try. I hope you theory turns out to be realistic. :)
Here are some examples why bridging between Neutron internal networks using 
trunk network and L2GW IMO should be avoided. I am still fine with bridging to 
external networks.

Assuming VM with trunk port wants to use floating IP on specific VLAN. Router 
has to be created on a Neutron network behind L2GW since Neutron router cannot 
handle VLANs. (Maybe not too common use case, but just to show what kind of 
issues you can get into)
neutron floatingip-associate FLOATING_IP_ID INTERNAL_VM_PORT_ID
The code to check if valid port has to be able to traverse the L2GW. Handing of 
IP addresses of VM will most likely be affected since VM port is connected to 
several broadcast domains. Alternatively new API can be created.

Now, this is a very good argument for 'trunk ports', yes.  It's not actually an 
argument against bridging between networks.  I think the bridging case 
addresses use cases (generally NFV use cases) where you're not interested in 
Openstack managing addresses - often because you're forwarding traffic rather 
than being an endpoint, and/or you plan on disabling all firewalling for speed 
reasons, but perhaps because you wish to statically configure an address rather 
than use DHCP.  The point is that, in the absence of a need for address-aware 
functions, you don't really care much about ports, and in fact configuring 
ports with many addresses may simply be overhead.  Also, as you say, this 
doesn't address the external bridging use case where what you're bridging to is 
not necessarily in Openstack's domain of control.
I know that many NFVs currently prefer to manage everything themselves. At the 
same time, IMO, I think they should be encouraged to become Neutronified.
In “VLAN aware VMs” trunk port mac address has to be globally unique since it 
can be connected to any network, other ports still only has to be unique per 
network. But for L2GW all mac addresses has to be globally unique since they 
might be bridged together at a later stage.

I'm not sure that that's particularly a problem - any VM with a port will have 
one globally unique MAC address.  I wonder if I'm missing the point here, 
though.
Ok, this was probably too specific, sorry. Neutron can reuse MAC addresses 
among Neutron networks. But I guess this is configurable.
Also some implementations might not be able to take VID into account when doing 
mac address learning, forcing at least unique macs on a trunk network.

If an implementation struggles with VLANs then the logical thing to do would be 
not to implement them in that 

[openstack-dev] [neutron][L3][DVR][arp]

[Wuhongning]

Is it a good idea to add a configuration item for dvr, to disable any arp entry 
processing, and reuse arp response from L2population?

When no static arp entry is found in qrouter namespace, it would cause a temp 
arp request, then it reached the br-tun, and replied by the OVS flow table.

In a public cloud like AWS, it allow 200 subnets for each vpc, so sync routes 
would waste a lot of time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][L3][DVR][arp]

[Wuhongning]

Some one posted a bug [1] for vlan arp responder and vlan l2population, which 
use the merged patch [2] for supporting the same thing in the ofagent



So for DVR for vlan, I think we can continue with the bug fix above.



From: huangdenghui [hdh_1...@163.com]
Sent: Sunday, November 29, 2015 4:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][L3][DVR][arp]

If those 200 subnets are VXLAN networks, i think it is a good idea, since 
L2population already  propagate this configuration to OVS-Agent.

One comment for VLAN network, since DVR also support in VLAN network and 
L2population is not necessary in it, what is your consideration in this case?




At 2015-11-29 14:15:11, "Wuhongning" <wuhongn...@huawei.com> wrote:
>Is it a good idea to add a configuration item for dvr, to disable any arp 
>entry processing, and reuse arp response from L2population?
>
>When no static arp entry is found in qrouter namespace, it would cause a temp 
>arp request, then it reached the br-tun, and replied by the OVS flow table.
>
>In a public cloud like AWS, it allow 200 subnets for each vpc, so sync routes 
>would waste a lot of time
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] OVS flow modification performance

[Wuhongning]

By our testing, ryu openflow has greatly improved the performance, with 500 
port vxlan flow table, from 15s to 2.5s, 6 times better.

From: IWAMOTO Toshihiro [iwam...@valinux.co.jp]
Sent: Monday, January 25, 2016 5:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] OVS flow modification performance

At Thu, 21 Jan 2016 02:59:16 +,
Wuhongning wrote:
>
> I don't think 400 flows can show the difference , do you have setup any 
> tunnel peer?
>
> In fact we may set the network type as "vxlan", then make a fake MD simulate 
> sending l2pop fdb add messages, to push ten's of thousands flows into the 
> testing ovs agent.

I chose this method because I didn't want to write such extra code for
measurements. ;)
Of course, I'd love to see data from other test environments and other
workload than agent restarts.

Also, we now have https://review.openstack.org/#/c/271939/ and can
profile neutron-server (and probably others, too).
I couldn't find non-trivial findings until now, though.

> 
> From: IWAMOTO Toshihiro [iwam...@valinux.co.jp]
> Sent: Monday, January 18, 2016 4:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] OVS flow modification performance
>
> At Mon, 18 Jan 2016 00:42:32 -0500,
> Kevin Benton wrote:
> >
> > Thanks for doing this. A couple of questions:
> >
> > What were your rootwrap settings when running these tests? Did you just
> > have it calling sudo directly?
>
> I used devstack's default, which runs root_helper_daemon.
>
> > Also, you mention that this is only ~10% of the time spent during flow
> > reconfiguration. What other areas are eating up so much time?
>
>
> In another run,
>
> $ for f in `cat tgidlist.n2`; do echo -n $f; opreport -n tgid:$f --merge 
> tid|head -1|tr -d '\n'; (cd bg; opreport -n tgid:$f --merge tid|head 
> -1);echo; done|sort -nr -k +2
> 10071   239058 100.000 python2.714922 100.000 python2.7
> 999592328 100.000 python2.711450 100.000 python2.7
> 757988202 100.000 python2.7(18596)
> 1109451560 100.000 python2.747964 100.000 python2.7
> 703549687 100.000 python2.740678 100.000 python2.7
> 1109349380 100.000 python2.736004 100.000 python2.7
> (legend:
>  )
>
> These processes are neutron-server, nova-api,
> neutron-openvswitch-agent, nova-conductor, dstat and nova-conductor in
> a decending order.
>
> So neutron-server uses about 3x CPU time than the ovs agent,
> nova-api's CPU usage is similar to the ovs agent's, and the others
> aren't probably significant.
>
> > Cheers,
> > Kevin Benton
> >
> > On Sun, Jan 17, 2016 at 10:12 PM, IWAMOTO Toshihiro <iwam...@valinux.co.jp>
> > wrote:
> >
> > > I'm sending out this mail to share the finding and discuss how to
> > > improve with those interested in neutron ovs performance.
> > >
> > > TL;DR: The native of_interface code, which has been merged recently
> > > and isn't default, seems to consume less CPU time but gives a mixed
> > > result.  I'm looking into this for improvement.
> > >
> > > * Introduction
> > >
> > > With an ML2+ovs Neutron configuration, openflow rule modification
> > > happens often and is somewhat a heavy operation as it involves
> > > exec() of the ovs-ofctl command.
> > >
> > > The native of_interface driver doesn't use the ovs-ofctl command and
> > > should have less performance impact on the system.  This document
> > > tries to confirm this hypothesis.
> > >
> > >
> > > * Method
> > >
> > > In order to focus on openflow rule operation time and avoid noise from
> > > other operations (VM boot-up, etc.), neutron-openvswitch-agent was
> > > restarted and the time it took to reconfigure the flows was measured.
> > >
> > > 1. Use devstack to start a test environment.  As debug logs generate
> > >considable amount of load, ENABLE_DEBUG_LOG_LEVEL was set to false.
> > > 2. Apply https://review.openstack.org/#/c/267905/ to enable
> > >measurement of flow reconfiguration times.
> > > 3. Boot 80 m1.nano instances.  In my setup, this generates 404 br-int
> > >flows.  If you have >16G RAM, more could be booted.
> > > 4. Stop neutron-openvswitch-agent and restart with --run-once arg.
> > >Use time, oprofile, and python's cProfile (use --profile arg) to
> > >collect data.
> > >
> > > * Results
>

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

[Wuhongning]

I've not done any test on AWS yet.

But it seems that a simple optimization could be introduced for huge 
improvement: add a config item to let l3 agent remove all arp entry rpc, and 
reuse arp response by l2pop (if the admin choose to enable it)


From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, February 23, 2016 10:51 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results 
and scenarios

On 02/22/2016 10:25 PM, Wuhongning wrote:
> Hi all,
>
> There is also a control plane performance issue when we try to catch on
> the spec of typical AWS limit (200 subnets per router). When a router
> with 200 subnets is scheduled on a new host, a 30s delay is watched when
> all data plane setup is finished.

How quickly does AWS do the same setup?

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

[Wuhongning]

Hi all,



There is also a control plane performance issue when we try to catch on the 
spec of typical AWS limit (200 subnets per router). When a router with 200 
subnets is scheduled on a new host, a 30s delay is watched when all data plane 
setup is finished.






From: Vasudevan, Swaminathan (PNB Roseville) [swaminathan.vasude...@hpe.com]
Sent: Saturday, February 20, 2016 1:49 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Yuli Stremovsky; Shlomo Narkolayev; Eran Gampel
Subject: Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results 
and scenarios

Hi Gal Sagie,
Let me try to pull in the data and will provide you the information.
Thanks
Swami

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: Thursday, February 18, 2016 9:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Yuli Stremovsky; Shlomo Narkolayev; Eran Gampel
Subject: Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results 
and scenarios

Hi Swami,

Thanks for the reply, is there any detailed links that describe this that we 
can look at?

(Of course that having results without the full setup (hardware/ NIC, CPU and 
threads for OVS and so on..) details
and without the full scenario details is a bit hard, regardless however i hope 
it will give us at least
an estimation where we are at)

Thanks
Gal.

On Thu, Feb 18, 2016 at 9:34 PM, Vasudevan, Swaminathan (PNB Roseville) 
> wrote:
Hi Gal Sagie,
Yes there was some performance results on DVR that we shared with the community 
during the Liberty summit in Vancouver.

Also I think there was a performance analysis that was done by Oleg Bondarev on 
DVR during the Paris summit.

We have done lot more changes to the control plane to improve the scale and 
performance in DVR during the Mitaka cycle and will be sharing some performance 
results in the upcoming summit.

Definitely we can align on our approach and have all those results captured in 
the upstream for the reference.

Please let me know if you need any other information.

Thanks
Swami

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: Thursday, February 18, 2016 6:06 AM
To: OpenStack Development Mailing List (not for usage questions); Eran Gampel; 
Shlomo Narkolayev; Yuli Stremovsky
Subject: [openstack-dev] [Neutron] - DVR L3 data plane performance results and 
scenarios

Hello All,

We have started to test Dragonflow [1] data plane L3 performance and was 
wondering
if there is any results and scenarios published for the current Neutron DVR
that we can compare and learn the scenarios to test.

We mostly want to validate and understand if our results are accurate and also 
join the
community in defining base standards and scenarios to test any solution out 
there.

For that we also plan to join and contribute to openstack-performance [2] 
efforts which to me
are really important.

Would love any results/information you can share, also interested in control 
plane
testing and API stress tests (either using Rally or not)

Thanks
Gal.

[1] http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
[2] https://github.com/openstack/performance-docs

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best Regards ,

The G.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] OVS flow modification performance

[Wuhongning]

I don't think 400 flows can show the difference , do you have setup any tunnel 
peer?

In fact we may set the network type as "vxlan", then make a fake MD simulate 
sending l2pop fdb add messages, to push ten's of thousands flows into the 
testing ovs agent.


From: IWAMOTO Toshihiro [iwam...@valinux.co.jp]
Sent: Monday, January 18, 2016 4:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] OVS flow modification performance

At Mon, 18 Jan 2016 00:42:32 -0500,
Kevin Benton wrote:
>
> Thanks for doing this. A couple of questions:
>
> What were your rootwrap settings when running these tests? Did you just
> have it calling sudo directly?

I used devstack's default, which runs root_helper_daemon.

> Also, you mention that this is only ~10% of the time spent during flow
> reconfiguration. What other areas are eating up so much time?


In another run,

$ for f in `cat tgidlist.n2`; do echo -n $f; opreport -n tgid:$f --merge 
tid|head -1|tr -d '\n'; (cd bg; opreport -n tgid:$f --merge tid|head -1);echo; 
done|sort -nr -k +2
10071   239058 100.000 python2.714922 100.000 python2.7
999592328 100.000 python2.711450 100.000 python2.7
757988202 100.000 python2.7(18596)
1109451560 100.000 python2.747964 100.000 python2.7
703549687 100.000 python2.740678 100.000 python2.7
1109349380 100.000 python2.736004 100.000 python2.7
(legend:
 )

These processes are neutron-server, nova-api,
neutron-openvswitch-agent, nova-conductor, dstat and nova-conductor in
a decending order.

So neutron-server uses about 3x CPU time than the ovs agent,
nova-api's CPU usage is similar to the ovs agent's, and the others
aren't probably significant.

> Cheers,
> Kevin Benton
>
> On Sun, Jan 17, 2016 at 10:12 PM, IWAMOTO Toshihiro 
> wrote:
>
> > I'm sending out this mail to share the finding and discuss how to
> > improve with those interested in neutron ovs performance.
> >
> > TL;DR: The native of_interface code, which has been merged recently
> > and isn't default, seems to consume less CPU time but gives a mixed
> > result.  I'm looking into this for improvement.
> >
> > * Introduction
> >
> > With an ML2+ovs Neutron configuration, openflow rule modification
> > happens often and is somewhat a heavy operation as it involves
> > exec() of the ovs-ofctl command.
> >
> > The native of_interface driver doesn't use the ovs-ofctl command and
> > should have less performance impact on the system.  This document
> > tries to confirm this hypothesis.
> >
> >
> > * Method
> >
> > In order to focus on openflow rule operation time and avoid noise from
> > other operations (VM boot-up, etc.), neutron-openvswitch-agent was
> > restarted and the time it took to reconfigure the flows was measured.
> >
> > 1. Use devstack to start a test environment.  As debug logs generate
> >considable amount of load, ENABLE_DEBUG_LOG_LEVEL was set to false.
> > 2. Apply https://review.openstack.org/#/c/267905/ to enable
> >measurement of flow reconfiguration times.
> > 3. Boot 80 m1.nano instances.  In my setup, this generates 404 br-int
> >flows.  If you have >16G RAM, more could be booted.
> > 4. Stop neutron-openvswitch-agent and restart with --run-once arg.
> >Use time, oprofile, and python's cProfile (use --profile arg) to
> >collect data.
> >
> > * Results
> >
> > Execution time (averages of 3 runs):
> >
> > native 28.3s user 2.9s sys 0.4s
> > ovs-ofctl  25.7s user 2.2s sys 0.3s
> >
> > ovs-ofctl runs faster and seems to use less CPU, but the above doesn't
> > count in execution time of ovs-ofctl.
> >
> > Oprofile data collected by running "operf -s -t" contain the
> > information.
> >
> > With of_interface=native config, "opreport tgid:" shows:
> >
> >samples|  %|
> > --
> > 87408 100.000 python2.7
> > CPU_CLK_UNHALT...|
> >   samples|  %|
> > --
> > 69160 79.1232 python2.7
> >  8416  9.6284 vmlinux-3.13.0-24-generic
> >
> > and "opreport --merge tgid" doesn't show ovs-ofctl.
> >
> > With of_interface=ovs-ofctl, "opreport tgid:" shows:
> >
> >samples|  %|
> > --
> > 62771 100.000 python2.7
> > CPU_CLK_UNHALT...|
> >   samples|  %|
> > --
> > 49418 78.7274 python2.7
> >  6483 10.3280 vmlinux-3.13.0-24-generic
> >
> > and  "opreport --merge tgid" shows CPU consumption by ovs-ofctl
> >
> > 35774  3.5979 ovs-ofctl
> > CPU_CLK_UNHALT...|
> >   samples|  %|
> > --
> > 28219 78.8813 vmlinux-3.13.0-24-generic
> >  3487  9.7473 ld-2.19.so
> >  2301  6.4320 ovs-ofctl
> >
> > Comparing 87408 (native python) with 62771+35774, the native
> > of_interface uses 0.4s less CPU time