Current Series Release Notes¶

18.0.0-35¶

Adds the --remove-before-date argument to the admin job. It removes backups before the specified ISO datetime (YYYY-MM-DDTHH:MM:SS).

Added support for dynamic backup name templates in the Freezer agent. Administrators can now use placeholders such as {mode}, {hostname}, {resource_id}, {container}, and {storage} in –backup-name. If not configured, the agent automatically defaults to mode-specific template names (e.g. freezer_{mode}_{resource_id}).

Unified backup naming so that the resolved backup name is used for both the backend (e.g., the Cinder volume backup created in OpenStack) and the metadata payload registered in the Freezer API.

Cinder native backup jobs now support the cindernative_backup_az (CLI option --cindernative-backup-az) parameter, allowing users to specify the availability zone for backup operations.

Add –cindernative-backup-container parameter to the backup command for cindernative volume backups. This allows users to specify a custom container name or container template (supporting {project_id}, {volume_id}, and {backup_name}) separately from the global default container name.

Cinder native volume backups are now created with metadata tags (created_by: freezer and freezer_backup_id: <uuid>), allowing seamless tracking and correlation between Cinder backups and freezer-api records.

Added the cindernative_freezer_only configuration option (CLI flag --cindernative-freezer-only), defaulting to True. When enabled, Cinder rotation actions only manage and delete backups created by Freezer, preserving user-created manual volume backups.

A new configuration group scheduler has been introduced. All options related to the freezer-scheduler have been moved to this group. Previous options under DEFAULT group are still respected, though are considered deprecated.

freezer-scheduler can now run as a cluster. Multiple schedulers configured with the same client_id and a common tooz coordination backend (set via the new [coordination] backend_url option) share the jobs bound to that client_id: ownership is distributed with a consistent hash ring and each run is guarded by a per-job distributed lock, so jobs keep running when a member dies and are never executed twice concurrently. If the coordination backend is unreachable, members skip job execution (fail safe) until it is restored; a firing that cannot take its lock is retried with exponential backoff, so one-shot jobs are not lost while coordination is briefly unavailable. Coordination is opt-in: without backend_url the scheduler runs standalone as before. The tooz client library matching the chosen backend must be installed (e.g. tooz[redis]). Not supported in Windows service mode.

A new configuration section [service_auth] has been introduced and configuration of connection to Keystone is expected to be defined there.

The --remove-from-date argument is deprecated in favor of --remove-before-date. The deprecated argument will be removed in a future release.

The default value for the –backup-name configuration option has been changed from None to "freezer_{mode}_{resource_id}". This means that if –backup-name is omitted, backups will be dynamically named using this template instead of failing validation or using static fallbacks.

Make the –container CLI option optional for Cinder native restore jobs (–backup-media cindernative), as Cinder resolves the backup storage container internally from its database.

The DEFAULT group options related to the freezer-scheduler are considered deprecated. Please refer to the scheduler group options for more information.

Definition of keystone connection details in the [DEFAULT] section of freezer.conf is deprecated and will be removed in next releases.

Resolved multiple integration issues in the native Cinder backup driver (cindernative mode), including timezone-aware UTC datetime and timestamp comparison for rotation/cleanup, and fixing generator length check errors.

Cinder backup rotation actions now report deleted backup IDs to freezer-scheduler, which automatically deletes the corresponding backup entries in freezer-api.

freezer-scheduler now applies job definition changes made through freezer-api without needing a restart. Previously a job that was already scheduled kept executing the actions it was created with: the updated definition was fetched on every poll but only adopted when the job carried a pending start, stop or abort event, so editing a job (for example replacing its actions with PATCH /v2/jobs/{job_id}) had no effect until the job was stopped and started again or the scheduler was restarted. Changes to a job’s schedule are now applied as well, re-arming the trigger, except while the job is running or is being started, stopped or removed. Standalone (--no-api) mode is unaffected, as it reads its jobs directory once at startup.