Re: [MERGE] network-guru-orchestration into master

2013-10-29 Thread Darren Shepherd
First, I like the idea of consolidating logic. I could see also implementing this as just an abstract base class that handles this common logic. I'm not sure which approach I prefer. Exactly what is the problem that you are trying to solve? Without more details, I'd lean towards implementing th

Re: [MERGE] network-guru-orchestration into master

2013-10-30 Thread Murali Reddy
On 29/10/13 10:12 PM, "Hugo Trippaers" wrote: >Hey guys, > >This is something i had on my wish list for some time. The current way >network gurus are handled is that each guru is asked to design a network >and will decide by itself to either do it or donĀ¹t. Most gurus have sane >checks on which

Re: [MERGE] network-guru-orchestration into master

2013-10-30 Thread Hugo Trippaers
On 30 okt. 2013, at 02:09, Darren Shepherd wrote: > First, I like the idea of consolidating logic. I could see also > implementing this as just an abstract base class that handles this > common logic. I'm not sure which approach I prefer. Exactly what is > the problem that you are trying to s

Re: [MERGE] network-guru-orchestration into master

2013-10-30 Thread Darren Shepherd
I don't particular like saying that picking a Guru is based solely on that criteria. It should be much looser than that. If the problem you are trying to fix is two Gurus implement the same network then we need to set back a bit. I'd like Alex or Chiradeep to weigh in on this. Currently setupNe

RE: [MERGE] network-guru-orchestration into master

2013-10-30 Thread Alex Huang
n NetworkElement can work with the L2-L3 technology deployed. --Alex > -Original Message- > From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] > Sent: Wednesday, October 30, 2013 10:11 AM > To: dev@cloudstack.apache.org; Alex Huang; Chiradeep Vittal > Subject: Re: [MER

Re: [MERGE] network-guru-orchestration into master

2013-10-30 Thread Darren Shepherd
com] >> Sent: Wednesday, October 30, 2013 10:11 AM >> To: dev@cloudstack.apache.org; Alex Huang; Chiradeep Vittal >> Subject: Re: [MERGE] network-guru-orchestration into master >> >> I don't particular like saying that picking a Guru is based solely on that >

Re: [MERGE] network-guru-orchestration into master

2013-10-30 Thread Hugo Trippaers
ple, whether a certain NetworkElement can work with >> the L2-L3 technology deployed. >> >> --Alex >> >>> -Original Message- >>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] >>> Sent: Wednesday, October 30, 2013 10:11 AM >&

Re: [MERGE] network-guru-orchestration into master

2013-10-30 Thread Pedro Roque Marques
ts and >> NetworkGurus. For example, whether a certain NetworkElement can work with >> the L2-L3 technology deployed. >> >> --Alex >> >>> -Original Message- >>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] >>> Sent: Wedn

Re: [MERGE] network-guru-orchestration into master

2013-10-30 Thread Darren Shepherd
uld be deployed in a certain zone >>> and that's good enough. >>> >>> I do think there should be more tie in between the NetworkElements and >>> NetworkGurus. For example, whether a certain NetworkElement can work with >>> the L2-L3 technolog

Re: [MERGE] network-guru-orchestration into master

2013-10-30 Thread Darren Shepherd
On Wed, Oct 30, 2013 at 11:36 AM, Pedro Roque Marques wrote: > > Why ? That seems to me the most obvious way to do it. > There are different networking solutions: e.g. VLANs and overlays such as > OpenContrail that assume an L3 switching topology. For a deployment one > would tend to choose a s

Re: [MERGE] network-guru-orchestration into master

2013-10-30 Thread Marcus Sorensen
Here's a scenario... Lets say we currently have a zone deployed with Vlan isolation. There's nothing stopping us from running a vxlan isolation on the same hosts, even on the same physical interface. This is actually done in devcloud-kvm where public and mgmt traffic are selected by traffic label (

Re: [MERGE] network-guru-orchestration into master

2013-10-31 Thread Hugo Trippaers
On 31 okt. 2013, at 04:34, Marcus Sorensen wrote: > Here's a scenario... Lets say we currently have a zone deployed with Vlan > isolation. There's nothing stopping us from running a vxlan isolation on > the same hosts, even on the same physical interface. This is actually done > in devcloud-kvm

Re: [MERGE] network-guru-orchestration into master

2013-10-31 Thread Hugo Trippaers
the >>>> network services (L4-L7) provided on top of it. So I separated out >>>> NetworkGuru and NetworkElement. However, I didn't think it's likely that >>>> there would be two or three different type of L2-L3 technologies deployed >>>>

Re: [MERGE] network-guru-orchestration into master

2013-10-31 Thread Darren Shepherd
o it through capabilities. Why not just ask the system admin >>>>> to choose when they setup the zone? When I originally designed >>>>> NetworkGuru, I figured there's a difference in the L2-L3 technology >>>>> deployed and the network services (L4-

Re: [MERGE] network-guru-orchestration into master

2013-11-01 Thread Pedro Roque Marques
Darren, On Oct 31, 2013, at 10:05 AM, Darren Shepherd wrote: > Yeah I think it would be great to talk about this at CCC. I'm > hesitant to further narrow down the definition of the network. For > example, I think OpenStack's Neutron is fundamentally flawed because > they defined a network as

Re: [MERGE] network-guru-orchestration into master

2013-11-01 Thread Marcus Sorensen
On Fri, Nov 1, 2013 at 10:16 AM, Pedro Roque Marques wrote: > Darren, > > On Oct 31, 2013, at 10:05 AM, Darren Shepherd > wrote: > >> Yeah I think it would be great to talk about this at CCC. I'm >> hesitant to further narrow down the definition of the network. For >> example, I think OpenStac