+1 This is cool, Chiradeep!
I have one extra ask. While you're doing this work, please pay special attention to anything that requires a network plugin to call back into CloudStack or modifies CloudStack. Plugins should really just be dependent on cloud-utils and cloud-api and nothing else. They shouldn't have special access to any of the *Manager interfaces for example. This is one of the reasons why NetworkManager got so huge. Thanks for taking the lead on this! --Alex > -----Original Message----- > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > Sent: Friday, January 04, 2013 10:34 AM > To: CloudStack DeveloperList > Subject: Re: [PROPOSAL] Network Manager refactoring > > > > > > > > >> > >> Second, there can be a logical split between the public (service) > >>interface and > >> the orchestration interface. This should be as straightforward as not > >>making > >> NetworkManagerImpl inherit from NetworkService. > > > >Do I understand correctly that the idea here is to create a new "thing" > >that deals with the information requests as details in the NetworkService > >interface and leave the network manager responsible for just the doing > >the actual provisioning of networks and stuff? > > The NetworkService is the 'front-end' to the end-user API. These do not > concern themselves with things like deployment plans, vlans, isolation > methods etc. The NetworkManager is the one doing the actual grunt work, > including driving the plugins and gurus. > > In addition: > The NetworkManager is also used by other managers to 'find' stuff from the > database model. I feel by moving such stuff out, it clarifies the role of > the Network Manager as being the 'driver' of plugins.
