Current Series Release Notes

18.0.0.0rc1-26

Prelude

Freezer API resources are no longer binded to user_id, and are available for all users who are authorized to view them within the project.

Freezer API v1 support was removed in this release.

New Features

  • Added new configuration section [centralized_scheduler] which contains options to enable centralized scheduler and following options:

    • enabled - Enable centralized scheduler

    • service_user (required) - Service user ID or name for centralized scheduler

    • service_user_domain (optional) - ID or Name of the domain where “service_user” is located

    • trusts_delegated_roles - List of roles to be delegated to the service user. By default only member role will be delegated.

    This allows to create trusts for service user to perform actions on behalf of users, when freezer-scheduler runs in the centralized mode. Users trust ID will be included in response to Jobs API calls, which will allow centralized scheduler to act on behalf of the user.

  • A new parameter all_projects has been added to the GET /v2/jobs endpoint. When set to True, it will return all jobs regardless of the project owning them.

    This call requires passing the jobs:get_all_projects policy for the authenticated user.

  • Introduced a config option [centralized_scheduler]/auth_section to specify the auth section to be used to identify the service user for which trust will be issued. Freezer API will complete an auth for the user to ensure it’s correctly autenticated and has the required roles. By default, it’s pointing to [keystone_authtoken] section.

  • Introduced a new configuration parameter [centralized_scheduler]/enforce_trusts. Default logic for API is to create trusts only when a client is registered with is_central property. If operator wants to create for each job regardless of the client it’s associated with, [centralized_scheduler]/enforce_trusts should be set to True. In case operator wants to disable creation of trusts on behalf of the user, [centralized_scheduler]/enabled should be set to False.

  • Introduced a new boolean parameter is_central for client registration. Clients marked as central are globally visible to all projects, facilitating the use of shared scheduler nodes in multi-project environments. Registration of central clients is governed by the new clients:create_central policy rule (defaulting to rule:admin_or_service). While these clients are visible globally, management and deletion remain restricted to the original owning project or system administrators.

Upgrade Notes

  • Previously all backup resources (like jobs, job actions, etc) were assigned to both project_id and user_id, which made them invisible for other users who were authorized in the project. This is now changed, and Freezer is aligned with generic OpenStack logic, where resources are pinned to the project, and not to a specific user within a project.

  • Freezer API now defaults to SQLAlchemy as the storage driver.

  • List upgrade notes here, or remove this section. All of the list items in this section are combined when the release notes are rendered, so the text needs to be worded so that it does not depend on any information only available in another section, such as the prelude. This may mean repeating some details.

  • Freezer API v1 support was removed and users are required to update their code to use the v2 API instead.

Deprecation Notes

  • Elasticsearch DB storage is deprecated and will be removed in the next release. The only supported storage driver is SQLAlchemy.

  • Configuration options [centralized_scheduler]/service_user and [centralized_scheduler]/service_user_domain are deprecated and will be removed in a future release. Use [centralized_scheduler]/auth_section instead.

Security Issues

  • Introduced secure RBAC policies for the API and updated default values for the API v2 in order to keep reasonable and minimaly viable privileges for API calls.

Other Notes

  • User name is removed from the database schema. Storing user name did not add any value to backups, user id is enough to identify the user. This also reduces the amount of data stored in the database.