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
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
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-
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
>>>>
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
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
(
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
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
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
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
>&
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
>
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
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
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
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
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
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
types of networks it can handle, but we have seen is
17 matches
Mail list logo
