3e1e0bd7ed
The older version of pylint being used does not work correctly under python 3. In order to be able to update the pylint job to run under python 3, we need to update the tool. This patch updates to the latest version at this time. It also updates and pins astroid, which was previously capped. Using a pin instead of a cap should let us avoid issues with new releases while being specific about which version to actually use. The import-error linter rule is disabled because it appears in Windows-related code that looks for modules we don't expect to be able to find on the CI system under Linux. The non-iterator-returned rule is disabled because it is erroring on a class that doesn't make sense (freezer.utils.utils.ReSizeStream does appear to honor the iterator protocol). Further investigation is probably warranted on this one. The public entry point for multiprocessing.SimpleQueue is the top-level multiprocessing module, not multiprocessing.queues. The linter correctly caught this error because the ctx argument was not being passed to the class. The fix is to use the top-level entry point to access the class. basestring is no longer defined under python 3. The fix is to use six.string_types, which correctly sets the alias to str or basestring. By using the library, we can avoid having to tell the linter to ignore the local customization. The linter also caught a base raise, without an exception specified and not in the context of an exception handler. I added an exception using the pattern from the one on an earlier line. Change-Id: I349de35c9ee52e2946e661f777308444b61ba4e0 Signed-off-by: Doug Hellmann <doug@doughellmann.com> Co-Authored-By: Nguyen Hai <nguyentrihai93@gmail.com> |
||
---|---|---|
config-generator | ||
devstack | ||
doc | ||
etc | ||
freezer | ||
playbooks/legacy/freezer | ||
releasenotes | ||
specs | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.pylintrc | ||
.stestr.conf | ||
.zuul.yaml | ||
CREDITS.rst | ||
FAQ.rst | ||
HACKING.rst | ||
INSTALL.rst | ||
LICENSE | ||
README.rst | ||
TODO.rst | ||
bindep.txt | ||
freezer_logo.jpg | ||
lower-constraints.txt | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini |
README.rst
Team and repository tags
OpenStack Freezer
Freezer is a Backup Restore DR as a Service platform that helps you to automate the data backup and restore process.
The following features are available:
- Backup file system using point-in-time snapshot
- Strong encryption supported: AES-256-CFB
- Backup file system tree directly (without volume snapshot)
- Backup journalled MongoDB directory tree using lvm snapshot to Swift
- Backup MySQL with lvm snapshot
- Restore data from a specific date automatically to file system
- Low storage consumption as the backup are uploaded as a stream
- Flexible backup policy (incremental and differential)
- Data is archived in GNU Tar format for file based incremental
- Multiple compression algorithm support (zlib, bzip2, xz)
- Remove old backup automatically according to the provided parameters
- Multiple storage media support (Swift, local file system, or ssh)
- Flush kernel buffered memory to disk
- Multi-platform (Linux, Windows, *BSD, OSX)
- Manage multiple jobs (I.e., multiple backups on the same node)
- Synchronize backups and restore on multiple nodes
- Web user interface integrated with OpenStack Horizon
- Execute scripts/commands before or after a job execution
- More ...
To learn how to use Freezer's API, consult the documentation available online at:
Freezer Disaster Recovery: - Freezer DR
Freezer Horizon plugin: - Freezer Web UI
For more information on OpenStack APIs, SDKs and CLIs in general, refer to:
Operators
To learn how to deploy and configure OpenStack Freezer, consult the documentation available online at:
In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at:
Developers
Any new code must follow the development guidelines detailed in the HACKING.rst file and OpenStack general development guidelines, and pass all unit tests.
Further developer focused documentation is available at:
Other Information
Release notes for the project can be found at:
During each Summit and Project Team Gathering, we agree on what the whole community wants to focus on for the upcoming release. The plans for freezer can be found at: