From de0c187307a6b98a2e75630c70a73d08b9992c66 Mon Sep 17 00:00:00 2001 From: Angus Salkeld Date: Tue, 11 Sep 2012 15:43:33 +1000 Subject: Add the rpc service and delete manager Part of blueprint service-infrastructure Change-Id: Ie00efcb1c974d699ac6b2a38285abef1b295f3ce --- openstack/common/manager.py | 68 --------------------------------------------- 1 file changed, 68 deletions(-) delete mode 100644 openstack/common/manager.py (limited to 'openstack/common/manager.py') diff --git a/openstack/common/manager.py b/openstack/common/manager.py deleted file mode 100644 index 647fa93..0000000 --- a/openstack/common/manager.py +++ /dev/null @@ -1,68 +0,0 @@ -# vim: tabstop=4 shiftwidth=4 softtabstop=4 - -# Copyright 2010 United States Government as represented by the -# Administrator of the National Aeronautics and Space Administration. -# All Rights Reserved. -# -# Licensed under the Apache License, Version 2.0 (the "License"); you may -# not use this file except in compliance with the License. You may obtain -# a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT -# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the -# License for the specific language governing permissions and limitations -# under the License. - -"""Base Manager class. - -Managers are responsible for a certain aspect of the system. It is a logical -grouping of code relating to a portion of the system. In general other -components should be using the manager to make changes to the components that -it is responsible for. - -For example, other components that need to deal with volumes in some way, -should do so by calling methods on the VolumeManager instead of directly -changing fields in the database. This allows us to keep all of the code -relating to volumes in the same place. - -We have adopted a basic strategy of Smart managers and dumb data, which means -rather than attaching methods to data objects, components should call manager -methods that act on the data. - -Methods on managers that can be executed locally should be called directly. - -Managers should be responsible for most of the db access, and -non-implementation specific data. Anything implementation specific that can't -be generalized should be done by the Driver. - -In general, we prefer to have one manager with multiple drivers for different -implementations, but sometimes it makes sense to have multiple managers. You -can think of it this way: Abstract different overall strategies at the manager -level(FlatNetwork vs VlanNetwork), and different implementations at the driver -level(LinuxNetDriver vs CiscoNetDriver). - -Managers will often provide methods for initial setup of a host or periodic -tasks to a wrapping service. - -This module provides Manager, a base class for managers. - -""" - -from openstack.common import periodic_task - - -class Manager(periodic_task.PeriodicTasks): - - def __init__(self, host): - self.host = host - - def init_host(self): - """Handle initialization if this is a standalone service. - - Child classes should override this method. - - """ - pass -- cgit