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 Wed, 30 Oct 2013 17:11:27 GMT
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 single invocation to
setupNetwork expects (and mostly hard code) a response of one network.

So for a more proper fix I'd say that the API of setupNetwork should
just 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 the 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.


On Wed, Oct 30, 2013 at 6:10 AM, Hugo Trippaers <> wrote:
> 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 solve?  Without more details, I'd
>> 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 network 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 can make an informed decision on who to give the task (and
warn if there 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 more tests.
>>> Cheers,
>>> Hugo

View raw message