old_contents: # 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.
  
  """
  
  
  class Manager(object):
  
      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
  
new_contents: # 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
  
subject: Add basic periodic task infrastructure.