cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <>
Subject Re: [MERGE] network-guru-orchestration into master
Date Thu, 31 Oct 2013 17:05:16 GMT
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 a L2 segment.  During my time that I was
away from CloudStack the physical network concept was added as a first
class object in CloudStack.  I don't know if I fully agree with it.  I
have to dig deeper and just haven't had the time to.  My inclination
is that is was one step too far and that it isn't really needed.  I
know you need to associate traffic with essentially a bridge on the
hypervisor, but that can be done with just labelling the network
offering that created the network.  So I need to dig into this

In the world of SDN, I think its even more important to keep the
definition of the a network loose.  SDN has the capability of
completely changing the way we look at L2 and L3.  Currently in
networking we group things by L3 and L2 concepts as that is how
routers and switches are laid out today.  As SDN matures and you see
more flow oriented design it won't make sense to group things using L2
and L3 concepts (as those become more a physical fabric technology),
the groups becomes more loose and thus the definition of a network
should be loose.

Now that's not to say that a network can't provide L2 and L3
information.  You should be able to create a network in CloudStack and
based on the configuration you know that it is a single L2 or L3.  It
is just that the core orchestration system can't make that fundamental
assumption.  I'd be interested in furthering the model and maybe
adding a concept of a L2 network such that a network guru when
designing a network, can define multiple l2networks and associate them
with the generic network that was created.  That idea I'm still
toiling with.

For example, when configuring DHCP on the systemvm.  DHCP is a L2
based serviced.  So to configure DHCP you really need to know for each
nic, what is the L2 its attached to and what are the VMs associated
with that L2.  Today, since there is no first class concept of a L2
network, you have to look at the implied definition of L2.  For basic
networks, the L2 is the Pod, so you need to list all VMs in that Pod.
For guest/VPC networks, the L2 is the network object, so you need to
list all VMs associated with the network.  It would be nice if when
the guru designed the network, it also defined the l2networks, and
then when a VM starts the guru the reserve() method could associate
the l2network to the nic.  So the nic object would have a network_id
and a l2_network_id.

I've gone off on a total tangent, but yeah, we should talk.


On Thu, Oct 31, 2013 at 2:53 AM, Hugo Trippaers <> wrote:
> On 31 okt. 2013, at 03:48, Darren Shepherd <> wrote:
>> Its important to remember that the definition of a Network in
>> CloudStack is quite purposefully very loose.  A network in the
>> simplest terms is just a group of VMs.  A guru creates and manages
>> that network.  A network is not strictly defined as a union of
>> traffictype/isolationtype/networktype/guesttype.  So, for example,
>> there need not be a 1-to-1 mapping between Guru and IsolationType.
>> You should be able to have multiple gurus per any context.  That's the
>> theory and vision.
> I think that vision was put down somewhere before we entered the era of software defined
networking. At the moment it is simply not true as long as the guru is responsible for creating
the overlay networks there is a 1 on 1 relation with the guru and the supported isolation
types in several cases.
>> Now the reality is that the current selection logic of the guru in the
>> orchestrator doesn't fully back up that vision because the selection
>> logic too easily allows two Guru's to implement the same network.
>> So I think the current behavior of setupNetwork is flawed.  This
>> change, I feel, muddies to a certain degree the definition of a
>> network in CloudStack and attempts to say a network is strict union of
>> traffic/isolation/network/guest-type.  If we merge this change, does
>> it hurt anything?  No, its more just conceptual disagreement.  When I
>> get to the point that I feel setupNetwork is limiting what I want to
>> do, I'll propose a change.  Right now, I just accept that its not
>> right in my mind.
> I’ve fixed the definition of setupNetwork so the function returns a single network
when called. This was already the effective behavior, but now its put down in code as well.
I’ll push that change to the branch today.
>> So I'd have to say I'm neutral on this change.  I don't care too much
>> either way as I think down the line this all needs to change.
> Let’s find a moment to sit down at CCCEU and discuss this further. I have some ideas
of where i want to go with the networking bit as well and it would be nice if we are more
or less on the same page before we start working on it. Saying that you don’t care because
you think its going to change it anyway isn’t really the best way to approach this.
>> Darren
>> On Wed, Oct 30, 2013 at 11:36 AM, Pedro Roque Marques
>> <> wrote:
>>> On Oct 30, 2013, at 11:08 AM, Darren Shepherd <>
>>>> I definitely don't want the setup to be done at a zone level.
>>> 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 solution
associated with the physical network.
>>>> Specifically, I'd like to get rid of the notion of basic and advanced
>>>> zones which would mean that you could be mixing gurus in the same
>>>> zone.  If anything, I'd say the simplest would be to just specify the
>>>> Guru in the network offering.
>>> Basic and advanced zones is rather unhelpful, i agree. But you still can't Mix
Guru's unless they can interoperate... The way for them to interop (i.e. minimum common denominator)
is to connect at L3 in an router between zones.
>>>> I like the work that Hugo has done, but the implications of that
>>>> change are 2 things.  First, we only want one guru to match.  If that
>>>> is the case, then lets change the NetworkOrchestrator.setupNetwork()
>>>> to just return one network.  I have a hard time understanding why you
>>>> would want to return two or more.  Even if the guru created two
>>>> networks internally, only one should be return to the caller.  There's
>>>> not a good way to invoke setupNetwork() and handle cases where more
>>>> than one network comes back.
>>>> Second, we are saying the only way to choose a guru is based on
>>>> networkType/trafficType/guestType/isolationmethods.  I think the core
>>>> logic should be more flexible than that.  We can first check those 4
>>>> items, and then if we find more than one guru that matches, use the
>>>> best one (before what I said about adding canHandle to the interface).
>>>> But the check shouldn't be only those four criteria.  Hugo's change
>>>> does not strictly enforce that, but it is essentially implied.
>>>> After saying all that, if we just put the Guru in the network
>>>> offering.  Would that work for everything?  That would be a really
>>>> simple and explicit way to configure this all.
>>> My preference would be for a NetworkManager per zone.
>>>> Darren
>>>> On Wed, Oct 30, 2013 at 10:31 AM, Alex Huang <>
>>>>> I agree with Hugo that the current way of ask NetworkGuru to decide itself
is not desirable.  It makes absolute sense to change that but I wonder why do 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-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 within the same zone.  I figured we can leave it to the system admin
to just pick which set of NetworkGurus should be deployed in a certain zone and that's good
>>>>> 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 technology
>>>>> --Alex
>>>>>> -----Original Message-----
>>>>>> From: Darren Shepherd []
>>>>>> Sent: Wednesday, October 30, 2013 10:11 AM
>>>>>> To:; 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 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 setupNetwork returns
a list
>>>>>> of networks that were created.  I've looked at the code and every
>>>>>> invocation to setupNetwork expects (and mostly hard code) a response
>>>>>> one network.
>>>>>> So for a more proper fix I'd say that the API of setupNetwork should
>>>>>> return Network.  Additionally NetworkGuru should have a
>>>>>> canHandle/canDesign method on the interface that returns a priority/score
>>>>>> (similar to what was just done in the storage strategies).  Then
>>>>>> orchestrator can find the best match and then use the correct guru.
 Now the
>>>>>> consolidated logic that you've done should be in a abstract base
class that
>>>>>> handles the basic cases of traffic type, network type, etc.
>>>>>> Darren
>>>>>> On Wed, Oct 30, 2013 at 6:10 AM, Hugo Trippaers <>
>>>>>>> On 30 okt. 2013, at 02:09, Darren Shepherd <>
>>>>>> wrote:
>>>>>>>> First, I like the idea of consolidating logic.  I could see
>>>>>>>> implementing this as just an abstract base class that handles
>>>>>>>> common logic.  I'm not sure which approach I prefer.  Exactly
what is
>>>>>>>> the problem that you are trying to solve?  Without more details,
>>>>>>>> lean towards implementing this logic in an abstract base
class that
>>>>>>>> all NetworkGurus can choose to extend.
>>>>>>> Not as much a problem as a design choice. It is my intention
to use
>>>>>>> capabilities to select the NetworkGuru instead of asking each
>>>>>>> guru in turn if it wants to design the network. The idea here
is that
>>>>>>> new network gurus only need to supply a list of capabilities
to be
>>>>>>> integrated into cloudstack. Like i can handle isolation type
X in
>>>>>>> advanced networks for traffic type Guest. The network orchestrator
>>>>>>> make an informed decision on who to give the task (and warn if
>>>>>>> is more than one capable)
>>>>>>>> Darren
>>>>>>>> On Tue, Oct 29, 2013 at 9:42 AM, 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 types of networks it can handle, but we have seen issues there
in the
>>>>>> past.
>>>>>>>>> With these changes the network orchestrator will check
the capabilities
>>>>>> of a guru and based on that ask one or more gurus to design the network.
>>>>>> With this the power is where is should new, the network orchestrator.
>>>>>>>>> This also means that new networking plugins with gurus
will have an
>>>>>> easier integration, just list the capabilities. It will also save
some database
>>>>>> calls (once i clean out all canHandle functions) as gurus will have
to lookup
>>>>>> less to decide if they should to their job.
>>>>>>>>> What do you guys think?
>>>>>>>>> Current branch is tested with devcloud in a manual test,
so there is more
>>>>>> work to do there. I wanted to get some opinions while performing
>>>>>> tests.
>>>>>>>>> Cheers,
>>>>>>>>> Hugo

View raw message