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