incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: [PROPOSAL] Network Manager refactoring
Date Fri, 04 Jan 2013 20:28:38 GMT

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!


> -----Original Message-----
> From: Chiradeep Vittal []
> 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.

View raw message