On 30 okt. 2013, at 19:08, Darren Shepherd <darren.s.sheph...@gmail.com> wrote:
> I definitely don't want the setup to be done at a zone level. Pretty strong words, i’m considering this a veto on any further discussion around this topic? > 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. > > 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. Lets say that is a historical left over, there is no reason to return more than one network. The current method signature is still there, because nobody changed it yet. Feel free to submit a patch. > 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. Thats how it is currenty implemented, with the exception that we don’t know which is the best one. So we loop through the remaining gurus and the first one that responds with a network wins. It would be very hard to give a score to a guru. > > 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. We need it to link to the physical network. The physical network is configured for a particular technology, usually out side cloudstack. Like configuring your hypervisors for Midonet or VMware NSX. You should not be able to mix different gurus on a physical network. The gurus are there to deal with the low-level network creation stuff. If anything, the gurus should be split into two different things. The first that deals with the isolation method (L2 networking) set on the physical network and the second that deals with the L3 stuff like how to assign IPs and such. > > Darren Hugo > > > 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 >>>>
