cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <darren.s.sheph...@gmail.com>
Subject Re: [MERGE] network-guru-orchestration into master
Date Wed, 30 Oct 2013 01:09:50 GMT
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.

Darren

On Tue, Oct 29, 2013 at 9:42 AM, Hugo Trippaers <hugo@trippaers.nl> 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

Mime
View raw message