~openstack-gd/nova/lp785816-joinedload

« back to all changes in this revision

Viewing changes to nova/manager.py

  • Committer: Todd Willey
  • Date: 2010-11-07 19:51:40 UTC
  • mto: (386.2.41 trunkdoc)
  • mto: This revision was merged to the branch mainline in revision 398.
  • Revision ID: todd@ansolabs.com-20101107195140-djbg5mkmbz0jc03w
Merge lp:~termie/nova/trunkdoc (via patch, since bzr though it was already merged)

Show diffs side-by-side

added added

removed removed

Lines of Context:
15
15
#    WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
16
16
#    License for the specific language governing permissions and limitations
17
17
#    under the License.
 
18
 
18
19
"""
19
 
Base class for managers of different parts of the system
 
20
Managers are responsible for a certain aspect of the sytem.  It is a logical
 
21
grouping of code relating to a portion of the system.  In general other
 
22
components should be using the manager to make changes to the components that
 
23
it is responsible for.
 
24
 
 
25
For example, other components that need to deal with volumes in some way,
 
26
should do so by calling methods on the VolumeManager instead of directly
 
27
changing fields in the database.  This allows us to keep all of the code
 
28
relating to volumes in the same place.
 
29
 
 
30
We have adopted a basic strategy of Smart managers and dumb data, which means
 
31
rather than attaching methods to data objects, components should call manager
 
32
methods that act on the data.
 
33
 
 
34
Methods on managers that can be executed locally should be called directly. If
 
35
a particular method must execute on a remote host, this should be done via rpc
 
36
to the service that wraps the manager
 
37
 
 
38
Managers should be responsible for most of the db access, and
 
39
non-implementation specific data.  Anything implementation specific that can't
 
40
be generalized should be done by the Driver.
 
41
 
 
42
In general, we prefer to have one manager with multiple drivers for different
 
43
implementations, but sometimes it makes sense to have multiple managers.  You
 
44
can think of it this way: Abstract different overall strategies at the manager
 
45
level(FlatNetwork vs VlanNetwork), and different implementations at the driver
 
46
level(LinuxNetDriver vs CiscoNetDriver).
 
47
 
 
48
Managers will often provide methods for initial setup of a host or periodic
 
49
tasksto a wrapping service.
 
50
 
 
51
This module provides Manager, a base class for managers.
20
52
"""
21
53
 
22
54
from nova import utils