 5fc7ee5f62
			
		
	
	5fc7ee5f62
	
	
	
		
			
			Provides a place for any drivers to potentially
setup graceful-shutdown code.
VMware driver's proper driver-lifecycle code included.
This is critical in environments where the the vmware
driver is setup and torn down at high frequency.
Prevents run-away vSphere by closing stateless
HTTP management sessions gracefully.
Change-Id: I67a91613643540243ab1210b333ed8e121f05802
related to bug: 1262288
Closes-bug: 1292583
		
	
		
			
				
	
	
		
			117 lines
		
	
	
		
			4.2 KiB
		
	
	
	
		
			Python
		
	
	
	
	
	
			
		
		
	
	
			117 lines
		
	
	
		
			4.2 KiB
		
	
	
	
		
			Python
		
	
	
	
	
	
| # 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. If
 | |
| a particular method must execute on a remote host, this should be done via rpc
 | |
| to the service that wraps the manager
 | |
| 
 | |
| 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 oslo.config import cfg
 | |
| 
 | |
| from nova.db import base
 | |
| from nova.openstack.common import log as logging
 | |
| from nova.openstack.common import periodic_task
 | |
| from nova import rpc
 | |
| 
 | |
| 
 | |
| CONF = cfg.CONF
 | |
| CONF.import_opt('host', 'nova.netconf')
 | |
| LOG = logging.getLogger(__name__)
 | |
| 
 | |
| 
 | |
| class Manager(base.Base, periodic_task.PeriodicTasks):
 | |
| 
 | |
|     def __init__(self, host=None, db_driver=None, service_name='undefined'):
 | |
|         if not host:
 | |
|             host = CONF.host
 | |
|         self.host = host
 | |
|         self.backdoor_port = None
 | |
|         self.service_name = service_name
 | |
|         self.notifier = rpc.get_notifier(self.service_name, self.host)
 | |
|         self.additional_endpoints = []
 | |
|         super(Manager, self).__init__(db_driver)
 | |
| 
 | |
|     def periodic_tasks(self, context, raise_on_error=False):
 | |
|         """Tasks to be run at a periodic interval."""
 | |
|         return self.run_periodic_tasks(context, raise_on_error=raise_on_error)
 | |
| 
 | |
|     def init_host(self):
 | |
|         """Hook to do additional manager initialization when one requests
 | |
|         the service be started.  This is called before any service record
 | |
|         is created.
 | |
| 
 | |
|         Child classes should override this method.
 | |
|         """
 | |
|         pass
 | |
| 
 | |
|     def cleanup_host(self):
 | |
|         """Hook to do cleanup work when the service shuts down.
 | |
| 
 | |
|         Child classes should override this method.
 | |
|         """
 | |
|         pass
 | |
| 
 | |
|     def pre_start_hook(self):
 | |
|         """Hook to provide the manager the ability to do additional
 | |
|         start-up work before any RPC queues/consumers are created. This is
 | |
|         called after other initialization has succeeded and a service
 | |
|         record is created.
 | |
| 
 | |
|         Child classes should override this method.
 | |
|         """
 | |
|         pass
 | |
| 
 | |
|     def post_start_hook(self):
 | |
|         """Hook to provide the manager the ability to do additional
 | |
|         start-up work immediately after a service creates RPC consumers
 | |
|         and starts 'running'.
 | |
| 
 | |
|         Child classes should override this method.
 | |
|         """
 | |
|         pass
 |