Jitendra Mahari
e738145344
scheduler: stop passing unused project_id to BackupsManager.create
The freezer-scheduler was passing project_id to
BackupsManager.create() in python-freezerclient, but the client
method never used it — project scoping is already handled by the
Keystone token embedded in the request URL
(/v2/{project_id}/backups). Passing it was a no-op that caused a
TypeError when the stock client (which does not accept the kwarg)
was used, silently failing the backup metadata upload step. The
job itself reported success (Swift data was written) but the backup
record never appeared in the freezer-api backups list.
Changes:
- freezer_scheduler.py: collapse upload_metadata() to always call
client.backups.create(metadata_doc) unconditionally; remove the
now-redundant if/else branch that forwarded project_id.
- scheduler_job.py: stop reading project_id from job_doc and
forwarding it to upload_metadata(); the parameter is no longer
used.
The upload_metadata() method signature retains project_id=None for
backwards compatibility but no longer forwards it.
This fix is the companion to the revert of the python-freezerclient
patch (I<freezerclient-change-id>) which had accepted project_id as
a workaround for the TypeError. With the caller fixed, that
workaround is no longer needed.
Validated end-to-end in a test deployment: the backup job completes,
the metadata record registers successfully ("Backup registered" log
line), and the backup appears in the freezer-api backups list.
Closes-Bug: #<bug-id>
Change-Id: Iecbfc88f98984899dd7a8ac0583ea64451f31e07
Signed-off-by: Jitendra Mahari <jitendra.mahari@rackspace.com>
2026-08-14 20:51:42 +05:30
2026-01-25 15:54:21 +00:00
2026-07-24 14:04:54 +02:00
2026-07-24 14:04:54 +02:00
2026-08-14 20:51:42 +05:30
2026-07-24 14:04:54 +02:00
2016-02-12 01:39:34 +00:00
2018-11-12 19:01:11 -05:00
2019-04-19 19:26:12 +00:00
2024-12-03 16:35:55 +00:00
2024-06-17 18:09:15 +02:00
2025-02-11 19:13:36 +02:00
2026-04-09 13:33:01 +00:00
2026-01-19 11:03:31 +00:00
2025-03-21 13:51:05 +00:00
2020-10-29 01:26:38 -07:00
2016-03-30 19:17:11 +01:00
2020-10-29 09:53:34 +08:00
2015-11-23 11:09:38 +00:00
2026-03-13 15:25:22 +01:00
2026-01-25 15:54:21 +00:00
2026-07-24 14:04:54 +02:00
2025-09-17 21:49:42 +00:00
2024-12-03 15:35:45 +00:00
2025-11-21 16:29:34 +00:00
2026-03-25 16:57:23 +01:00
OpenStack Freezer
Freezer is a Backup and Restore 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 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:
Troubleshooting
When errors occure, these are good places to check:
- freezer-api log: $HOME/log/freezer-api.log
-
/var/log/apache2/freezer-api.log
- freezer-agent log: $HOME/.freezer/freezer.log
- freezer-scheduler log:/var/log/freezer/scheduler.log
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:
Contributors are encouraged to join IRC
(#openstack-freezer on OFTC):
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: