Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

2014-11-18 Thread henry hly
Is FWaas L2/3 or L4/7? On Wed, Nov 19, 2014 at 11:10 AM, Sumit Naiksatam wrote: > On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif wrote: >> I agree with Paul as advanced services go beyond just L4-L7. Today, VPNaaS >> deals with L3 connectivity but belongs in advanced services. Where does >> E

[openstack-dev] [Glance] Recall for previous iscsi backend BP

2014-11-18 Thread henry hly
In the Previous BP [1], support for iscsi backend is introduced into glance. However, it was abandoned because of Cinder backend replacement. The reason is that all storage backend details should be hidden by cinder, not exposed to other projects. However, with more and more interest in "Converged

Re: [openstack-dev] [Glance] Recall for previous iscsi backend BP

2014-11-19 Thread henry hly
make sense for Ceph like All-in-one Store, I'm not sure if iscsi backend can be used the same way. On Wed, Nov 19, 2014 at 4:00 PM, Flavio Percoco wrote: > On 19/11/14 15:21 +0800, henry hly wrote: >> >> In the Previous BP [1], support for iscsi backend is introduced into &

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

2014-11-25 Thread henry hly
Hi Armando, Indeed agent-less solution like external controller is very interesting, and in some certain cases it has advantage over agent solution, e.g. software installation is prohibited on Compute Node. However, Neutron Agent has its irreplaceable benefits: multiple backends support like SRIO

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

2014-11-25 Thread henry hly
On Wed, Nov 26, 2014 at 12:14 AM, Mathieu Rohon wrote: > On Tue, Nov 25, 2014 at 9:59 AM, henry hly wrote: >> Hi Armando, >> >> Indeed agent-less solution like external controller is very >> interesting, and in some certain cases it has advantage over agent

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

2014-11-30 Thread henry hly
FWaas is typically classified to L4-L7. But if they are developed standalone, it would be very difficult for implementing with a distributed manner. For example, with W-E traffic control in DVR mode, we can't rely on a external python client rest api call, the policy execution module must be loaded

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-09 Thread henry hly
Hi Kevin, Does it make sense to introduce "GeneralvSwitch MD", working with VIF_TYPE_TAP? It just do very simple port bind just like OVS and bridge. Then anyone can implement their backend and agent without patch neutron drivers. Best Regards Henry On Fri, Dec 5, 2014 at 4:23 PM, Kevin Benton w

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-10 Thread henry hly
On Thu, Dec 11, 2014 at 12:36 AM, Kevin Benton wrote: > What would the port binding operation do in this case? Just mark the port as > bound and nothing else? > Also to set the vif type to tap, but don't care what the real backend switch is. ___ OpenSt

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

2014-12-10 Thread henry hly
On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells wrote: > On 10 December 2014 at 01:31, Daniel P. Berrange > wrote: >> >> >> So the problem of Nova review bandwidth is a constant problem across all >> areas of the code. We need to solve this problem for the team as a whole >> in a much broader fashion

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

2014-12-11 Thread henry hly
Maxime Leroy wrote: >> On Thu, Dec 11, 2014 at 11:41 AM, Daniel P. Berrange >> wrote: >> > On Thu, Dec 11, 2014 at 09:37:31AM +0800, henry hly wrote: >> >> On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells wrote: >> >> > On 10 December 2014 at 01:31, Dani

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-11 Thread henry hly
On Fri, Dec 12, 2014 at 11:41 AM, Dan Smith wrote: >> [joehuang] Could you pls. make it more clear for the deployment mode >> of cells when used for globally distributed DCs with single API. Do >> you mean cinder/neutron/glance/ceilometer will be shared by all >> cells, and use RPC for inter-dc co

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-12 Thread henry hly
On Fri, Dec 12, 2014 at 4:10 PM, Steve Gordon wrote: > - Original Message - >> From: "henry hly" >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> >> On Fri, Dec 12, 2014 at 11:41 AM, Dan Smith >> wr

Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change

2014-12-15 Thread henry hly
On Tue, Dec 16, 2014 at 1:53 AM, Neil Jerram wrote: > Hi all, > > Following the approval for Neutron vendor code decomposition > (https://review.openstack.org/#/c/134680/), I just wanted to comment > that it appears to work fine to have an ML2 mechanism driver _entirely_ > out of tree, so long as

[openstack-dev] [Neutron] Too much "shim rest proxy" mechanism drivers in ML2

2014-06-06 Thread henry hly
ML2 mechanism drivers are becoming another kind of "plugins". Although they can be loaded together, but can not work with each other. Today, there are more and more drivers, supporting all kinds of networking hardware and middleware (sdn controller). Unfortunately, they are designed exclusively as

Re: [openstack-dev] [Neutron] Too much "shim rest proxy" mechanism drivers in ML2

2014-06-09 Thread henry hly
hi mathieu, > I totally agree. By using l2population with tunnel networks (vxlan, > gre), you will not be able to plug an external device which could > possibly terminate your tunnel. The ML2 plugin has to be aware a new > port in the vxlan segment. I think this is the scope of this bp : > https:

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

2014-06-13 Thread henry hly
Hi car1, In the link: https://docs.google.com/document/d/1jCmraZGirmXq5V1MtRqhjdZCbUfiwBhRkUjDXGt5QUQ/edit, there is some words like " When the node is being scheduled to host the SNAT, a new namespace and internal IP address will be assigned to host the SNAT service. Any nova instance VM that i

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-04 Thread henry hly
Hi Monty and Cellers, I understand that there are installation base for Cells, these clouds are still running and some issues needed to be addressed for the daily operation. For sure the improvement on Cells are necessary to be done in first class for the community's commitment. The introduction

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-08 Thread henry hly
Hi, Good questions: why not just keeping multiple endpoints, and leaving orchestration effort in the client side? From feedback of some large data center operators, they want the cloud exposed to tenant as a single region with multiple AZs, while each AZ may be distributed in different/same locat

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-08 Thread henry hly
Hi Joshua, Absolutely internally improvement of single openstack is the first important thing, and there are already much effort in the community. For example, without optimization of security group, 200 nodes cluster would have serve performance problem, now with several patchs in Juno it's very

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-23 Thread henry hly
Hi Phil, Thanks for your feedback, and patience of this long history reading :) See comments inline. On Wed, Oct 22, 2014 at 5:59 PM, Day, Phil wrote: >> -Original Message- >> From: henry hly [mailto:henry4...@gmail.com] >> Sent: 08 October 2014 09:16 >> T

Re: [openstack-dev] [neutron]Performance of security group

2014-06-18 Thread henry hly
we have done some tests, but have different result: the performance is nearly the same for empty and 5k rules in iptable, but huge gap between enable/disable iptable hook on linux bridge On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang wrote: > Now I have not get accurate test data, but I can con

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

2014-06-18 Thread henry hly
OVS agent manipulate not only ovs flow table, but also linux stack, which is not so easily replaced by pure openflow controller today. fastpath-slowpath separation sounds good, but really a nightmare for high concurrent connection application if we set L4 flow into OVS (in our testing, vswitchd dae

[openstack-dev] [Neutron] [ML2] [arp] [l2pop] arp responding for vlan network

2015-02-03 Thread henry hly
Hi ML2'ers, We encounter use case of large amount of vlan network deployment, and want to reduce ARP storm by local responding. Luckily from Icehouse arp local response is implemented, however vlan is missed for l2pop. Then came this BP[1], which implement the plugin support of l2pop for configur

Re: [openstack-dev] ECMP on Neutron virtual router

2015-02-24 Thread henry hly
On Wed, Feb 25, 2015 at 3:11 AM, Kevin Benton wrote: > I wonder if there is a way we can easily abuse the extra routes extension to > do this? Maybe two routes to the same network would imply ECMP. > It's a good idea, and we deploy a system with similar concept(by extra routes) by a tiny patch on

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

2015-02-24 Thread henry hly
So are we talking about using script to eliminate unnecessary new vif types? Then, a little confusion that why this BP[1] is postponed to L, and this BP[2] is merged in K. [1] https://review.openstack.org/#/c/146914/ [2] https://review.openstack.org/#/c/148805/ In fact [2] can be replaced by [

[openstack-dev] [Neutron] [ML2] using binding:tun_ip instead of agent_ip for l2pop to support agentless backend

2015-03-25 Thread henry hly
Hi ML2er, Today we use agent_ip in L2pop to store endpoints for ports on a tunnel type network, such as vxlan or gre. However this has some drawbacks: 1) It can only work with backends with agents; 2) Only one fixed ip is supported per-each agent; 3) Difficult to interact with other backend and w

Re: [openstack-dev] [Neutron] [ML2] using binding:tun_ip instead of agent_ip for l2pop to support agentless backend

2015-04-02 Thread henry hly
nts might already have it embedded. >>> > >>> > last summit, we talked about this kind of idea [2]. We were going >>> > further >>> > by introducing the bgp speaker on each compute node, in use case B of >>> > [2]. >>> > >&

[openstack-dev] [neutron] [doc] what's happened to api documents?

2015-04-13 Thread henry hly
http://developer.openstack.org/api-ref-networking-v2.html The above api document seems lost most of the content, leaving only port, network, subnet? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [neutron] [doc] what's happened to api documents?

2015-04-13 Thread henry hly
Thanks a lot, henry :) On Mon, Apr 13, 2015 at 6:57 PM, Henry Gessau wrote: > On Mon, Apr 13, 2015, henry hly wrote: >> http://developer.openstack.org/api-ref-networking-v2.html >> >> The above api document seems lost most of the content, leaving only >> port,

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

2015-04-23 Thread henry hly
On Thu, Apr 23, 2015 at 10:44 AM, Armando M. wrote: >> >> Could you please also pay some attention on Cons of this ultimate >> splitting Kyle? I'm afraid it would hurt the user experiences. >> >> On the position of Dev, A naked Neutron without "official" built-in >> reference implementation probab