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 > >
