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
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,
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:
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].
>>> >
>&
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
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 [
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
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
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
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
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
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
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
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
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
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
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
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
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
&
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
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
Sent from my iPad
On 2014-10-30, at 下午8:05, Hly wrote:
> hi,
>
> Network reachability is not an issue for live migration, it is the same as
> cold. The challenge is near realtime order control of interaction between
> parent proxies, child virt drivers, agents, and libvi
hi,
Network reachability is not an issue for live migration, it is the same as
cold. The challenge is near realtime order control of interaction between
parent proxies, child virt drivers, agents, and libvirt lib.
Wu
Sent from my iPad
On 2014-10-30, at 下午7:28, joehuang wrote:
> Hello, Kesh
Sent from my iPad
On 2014-10-29, at 下午6:33, Maru Newby wrote:
>
> On Oct 29, 2014, at 8:12 AM, Yangxurong wrote:
>
>> Hi,
>>
>> I’m not sure whether following issue is problematic, and both, our team do
>> some effort, so I submit two blueprints:
>> [1.] optimize dvr flows:
>> Currently,
Sent from my iPad
On 2014-10-29, at 下午8:01, Robert van Leeuwen
wrote:
>>> I find our current design is remove all flows then add flow by entry, this
>>> will cause every network node will break off all tunnels between other
>>> network node and all compute node.
>> Perhaps a way around this w
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
在 2014-10-10，下午7:16，Salvatore Orlando 写道：
> Comments inline.
>
> Salvatore
>
> On 10 October 2014 11:02, Wuhongning wrote:
> 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.
> Withou
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
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
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
+1
Sent from my iPad
On 2014-7-12, at 下午11:45, Miguel Angel Ajo Pelayo wrote:
> +1
>
> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>
>
> -Original Message-
> From: Carl Baldwin [c...@ecbaldwin.net]
> Received: Saturday, 12 Jul 2014, 17:04
> To: OpenStack Devel
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
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
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
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:
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
36 matches
Mail list logo
