72de51b01c
This repo is now testing only with Python 3, so let's make a few cleanups: - Remove python 2.7 stanza from setup.py - Add requires on python >= 3.6 to setup.cfg so that pypi and pip know about the requirement - Remove obsolete sections from setup.cfg - Update classifiers - Update requirements, no need for python_version anymore - Switch to using sphinx-build with warnings enabled, fix warnings found with autodoc - Cleanup doc/source/conf.py to remove now obsolete content. - Use newer openstackdocstheme version, switch to using apidoc - Remove install_command from tox.ini, the default is fine - Change some imports to use python3 changed names Change-Id: Ibb2e614c7db8a01e41caed8314c1d46479c78295 |
||
|---|---|---|
| config-generator | ||
| doc | ||
| etc | ||
| freezer_dr | ||
| releasenotes/notes | ||
| tests | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .pylintrc | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| CREDITS.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| README.rst | ||
| bindep.txt | ||
| lower-constraints.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Team and repository tags
Freezer Disaster Recovery
freezer-dr, OpenStack Compute node High Available provides compute node high availability for OpenStack. Simply freezer-dr monitors all compute nodes running in a cloud deployment and if there is any failure in one of the compute nodes freezer-dr will fence this compute node then freezer-dr will try to evacuate all running instances on this compute node, finally freezer-dr will notify all users who have workload/instances running on this compute node as well as will notify the cloud administrators.
freezer-dr has a pluggable architecture so it can be used with:
- Any monitoring system to monitor the compute nodes (currently we support only native OpenStack services status)
- Any fencing driver (currently supports IPMI, libvirt, ...)
- Any evacuation driver (currently supports evacuate api call, may be migrate ??)
- Any notification system (currently supports email based notifications, ...)
just by adding a simple plugin and adjust the configuration file to use this plugin or in future a combination of plugins if required
freezer-dr should run in the control plane, however the architecture supports different scenarios. For running freezer-dr under high availability mode, it should run with active passive mode.
How it works
Starting freezer-dr:
- freezer-dr Monitoring manager is going to load the required monitoring driver according to the configuration
- freezer-dr will query the monitoring system to check if it considers any compute nodes to be down ?
- if no, freezer-dr will exit displaying No failed nodes
- if yes, freezer-dr will call the fencing manager to fence the failed compute node
- Fencing manager will load the correct fencer according to the configuration
- once the compute node is fenced and is powered off now we will start the evacuation process
- freezer-dr will load the correct evacuation driver
- freezer-dr will evacuate all instances to another computes
- Once the evacuation process completed, freezer-dr will call the notification manager
- The notification manager will load the correct driver based on the configurations
- freezer-dr will start the notification process ...