On Oct 30, 2013, at 11:08 AM, Darren Shepherd <darren.s.sheph...@gmail.com> wrote:
> 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 <alex.hu...@citrix.com> wrote: >> 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 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 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: [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 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. >>> >>> Darren >>> >>> On Wed, Oct 30, 2013 at 6:10 AM, Hugo Trippaers <h...@trippaers.nl> wrote: >>>> >>>> On 30 okt. 2013, at 02:09, Darren Shepherd <darren.s.sheph...@gmail.com> >>> 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 <h...@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 >>>>
