Xena Series Release Notes

8.0.1

Bug Fixes

  • Updating a lease with invalid parameters (for example, specifying an invalid date range) now has no effect on the lease, where previously this would cause the lease to be set to ERROR status. For more details, see bug 1786031.

  • Allows users of multiple Keystone domains to create leases; previously only users and projects in the default domain could use Blazar.

  • Fixes failure to update reservations when the resource_type parameter is not provided in the API request. For more details, see bug 1957761.

  • Fixes result of the List Allocations API for reservations with multiple physical hosts. For more details, see bug 1958307.

7.0.0

Upgrade Notes

  • The default value of the [oslo_policy]/policy_file configuration option has been changed from policy.json to policy.yaml. Operators using customized or previously generated static policy JSON files (which are not needed by default) should generate new policy files or convert them to YAML format. Use the oslopolicy-convert-json-to-yaml tool to convert a policy file from JSON to YAML in a backward-compatible way.

Deprecation Notes

  • Use of JSON-formatted policy files was deprecated by the oslo.policy library during the Victoria development cycle. As a result, this deprecation is being noted in the Wallaby cycle with an anticipated future removal of support by oslo.policy. As such operators will need to convert to YAML-formatted policy files. Please see the upgrade notes for details on migration of any custom policy files.

Bug Fixes

  • Fixes database migrations with Alembic 1.5.0 or greater. For more details, see bug 1912502.

6.0.0

Bug Fixes

  • Fixes host creation in the presence of availability zones with no hosts. For more details, see bug 1880646.

5.0.0

Upgrade Notes

  • Python 2.7 support has been dropped. The last release of Blazar supporting Python 2.7 is OpenStack Train. The minimum version of Python now supported by Blazar is Python 3.6.

Bug Fixes

  • Updates the on_start failure handlers to look up the freepool aggregate by ID, not by name, when moving hosts back to the freepool. Fixes issue where hosts wind up without any aggregate during lease start failure. For more details, see bug 1847821.

4.0.0

New Features

  • Blazar now supports API microversions. All API changes should be made while keeping backward compatibility. The API version is specified in the OpenStack-API-Version HTTP header. To view the mininum and maximum supported versions by API, access the / and /versions resources. The Blazar API will include supported versions in the response data.

  • Adds support for updating floating IP reservations, with some limitations. The amount of reserved floating IPs can be updated; however, updating network_id is denied and required_floatingips can only be changed to an empty list.

  • Adds support for global_request_id to the RequestId middleware. An inbound header of X-OpenStack-Request-ID is accepted as long as it is of the format req-$uuid, and made available to oslo.context. This allows for cross-project request ID tracking. By default, global request IDs will not appear in the Blazar service logs. Operators need to add global_request_id in the logging_context_format_string configuration option.

  • Blazar now uses oslo.middleware for request_id processing which will now return a new X-OpenStack-Request-ID header in the response to each Restful API request. Also, operators can see request_id, user_id and project_id by default in logs for better tracing and it is configurable via the [DEFAULT]/logging_context_format_string option.

Bug Fixes

  • Fixes placement operations in multi-region deployments.

Other Notes

3.0.0

Prelude

Added new tool blazar-status upgrade check.

New Features

  • New framework for blazar-status upgrade check command is added. This framework allows adding various checks which can be run before a Blazar upgrade to ensure if the upgrade can be performed safely.

  • Added a new resource plugin supporting floating IPs. This plugin enables users to reserve floating IPs from Neutron. To try the plugin, add virtual:floatingip to the [manager]/plugins configuration option in blazar.conf. For the API schema, see details of the APIs in the Lease API reference and Floating IP API reference.

    Note that this feature is available as a preview but is not yet complete. The Blazar CLI does not yet support it, documentation is incomplete, and the Update Lease API is not implemented. Floating IP reservation will be fully completed in the next release.

  • For instance reservation, the reservation parameter affinity now supports True and None and defaults to None

    • affinity = True

      • Blazar picks up the same host for the instances for the reservation. Using the reservation flavor, users don’t need to set additional specs such as “server_group” to schedule the instances to the host.

    • affinity = False

      • Blazar picks up different hosts for the instances for the reservation. Using the reservation flavor, users don’t need to set additional specs such as “server_group” to schedule to the hosts.

    • affinity = None (default)

      • The picked up hosts can be different or same.

    AggregateInstanceExtraSpecsFilter, AggregateMultiTenancyIsolation, or ServerGroupAffinityFilte is not needed any more for blazar’s instance reservation.

  • The List Allocations API and the Get Allocation API are newly implemented. The two APIs return list of mappings between a reservable resource and reservations. Currently Blazar only supports reservation of compute resources, so the APIs return mappings of hosts with reservation IDs of physical host reservations and instance reservations. See details of the API in the API reference .

Upgrade Notes

  • Operator can now use new CLI tool blazar-status upgrade check to check if Blazar deployment can be safely upgraded from N-1 to N release.

Bug Fixes

  • Fixes an issue wherein increasing the number of hosts of an active host reservation would fail to add newly allocated hosts to the host aggregate, preventing instances from being deployed on them.

  • If a host fails to be moved to a host aggregate while starting a reservation, any host previously moved into the same aggregate is now moved back to the freepool. This helps to prevent failures to start future leases allocating the same hosts.

  • Blazar now prevents leases from being deleted while their start_lease or end_lease events are in progress, to avoid concurrently accessing shared objects. For more details, see bug 1791741.

2.0.0

New Features

  • A time margin for cleaning up resources between the end of a lease and the start of the next lease is introduced. Leases are allocated to resources only if they have enough spare time for cleaning up before and after the lease. Note that this cleaning time is not included in the lease time, but is taken into account when looking for available resources. The length of cleaning time can be configured by the configuration option cleaning_time in the [DEFAULT] section. The default value for this option is 0, in which case the behavior is the same as previous releases.

  • Blazar handles availability zone information the compute host belongs to. When cloud operators add a compute host resource to the Blazar’s freepool, Blazar records the availability zone into it’s DB. The cloud user can specify the availability zone information by hypervisor_properties in the host reservation and by resource_properties in the instance reservation.

  • Resource monitoring supports periodic healing from the Rocky release. It only heals reservations starting within a configurable time window in order to avoid unnecessary reservation healing, e.g. when resources become available again at a later date. The interval is defined with the [physical:host]/healing_interval configuration option. The default value is 60 minutes. For more details, please see the Resource Monitoring section in the Blazar documentation. The previous mode of operation, which heals all reservations regardless of their start date, can be used by setting [physical:host]/healing_interval to 0.

  • Default policy for API access control has been moved from a file, e.g. policy.json, into codebase. Policy is basically defined in codebase but able to be changed by a policy file. See the policy configuration guide in detail.

  • The update host API denies update requests trying to change extra capabilities in use by any pending or active reservation. This avoids mismatches between updated extra capabilities and resource_properties specified before the update host request.

Known Issues

  • When the update lease API returns any error regardless of the reason, the lease status goes into ERROR. If the reason is wrong input, e.g. invalid format or not enough hosts available, updating the lease again with correct information will fix the ERROR status. For more details, see bug 1786031.

Upgrade Notes

  • The availability zone information is stored only when cloud operators add a new host to Blazar’s freepool. If the operators needs the information, please re-add hosts already registered in Blazar.

  • The default policy for the list and get hosts API is changed. Admin and its owner are allowed to call the API until Queens. From Rocky release, only the admin is allowed to call the API.

Bug Fixes

  • In the Blazar configuration, we have the following options:

    • os_admin_user_domain_name

    • os_admin_project_domain_name

    They are used for Keystone authentication. However, os_admin_project_domain_name in the configuration file was not reflected in Blazar. This was because internally in the Blazar service os_admin_user_domain_name was used wrongly for both the project domain name and the user domain name.

    This didn’t affect operators who set neither of the values explicitly in the configuration file, because the default values of the two options are both set to Default. This release fixes the bug for operators who set either of the values explicitly.

  • Some API responses are changed to use more appropriate status codes. The following requests will receive different response status codes:

    • Requesting instance reservation with affinity = True: 500 to 400

      • Instance reservation only accepts affinity = False until the plugin implements the Support no affinity rule blueprint. The Create Lease API and the Update Lease API now return 400 Bad Request instead of 500 Internal Server Error when affinity = True is specified.

    • Requesting end_date earlier than start_date in the Create Lease API: 202 to 400

      • The end_date parameter must be later than the start_date parameter. However, the Create Lease API was accepting requests where end_date is earlier than start_date, which was causing lease errors because of invalid status change. From the Rocky release, the API checks the ordering of the two events and returns an appropriate response status code.

    • Requesting invalid start_date or end_date in the Create Lease API and the Update Lease API: 403 to 400

      • 403 response code means an API request is Not Authorized. When the ordering of the two is invalid, the response status code is now 400 Bad Request, since the request is authorized but has an invalid request body.

    • Requesting an extra capability key longer than 64 characters: 500 to 400

      • The length of a host’s extra capability key is limited to a maximum of 64 characters. When a request body includes an extra capability longer than 64 characters, the response status code of the Create Host API and the Update Host API is now 400 Bad Request instead of 500 Internal Server Error.

    • Creating a new host/lease: 202 to 201

      • The Create Host API and the Create Lease API now return 201 Created instead of 202 Accepted, since Blazar ensures that a new host/lease is created before responding.

    • Updating a host/lease: 202 to 200

      • The Update Host API and the Update Lease API now return 200 OK instead of 202 Accepted, since Blazar ensures that a host/lease is updated before responding.

    • Requesting invalid date in the Create Lease API and the Update Lease API: 500 to 400

      • The start_date, end_date and before_end_date should be the format of “CCYY-MM-DD hh:mm” such as “2020-07-01 10:00”, otherwise it raises 400 Bad Request instead of 500 Internal Server Error.

Other Notes

  • The DevStack plugin now supports installing blazar-dashboard when both blazar and horizon services are enabled in local.conf.

  • Blazar now supports being run under Python 3. The Python 3 and Python 3.5 classifiers have been added.

  • All climate namespace is removed in Rocky release.

1.0.0

New Features

  • The resource monitoring feature is available from this release. This feature monitors states of resources in the freepool. If any failure is detected, reservations which suffer from the failure are healed. New flags have been introduced into leases and reservations to indicate health of reserved resources. Resource monitor is plugable and the compute host resource monitor is currently supported. See resource monitoring documentation in detail.

  • Lease status is introduced in this release. With this change, transition graphs of statuses of leases, reservations, and events are redefined while keeping backward compatibility. If you update Blazar from an older version, the lease status is automatically updated from None by an Alembic database migration script. See state machine documentation for more details.

0.4.0.0b2

New Features

  • A new Hosts panel is supported in the Reservation group of the Admin dashboard. The following operations are supported:

    • Show a list of hosts

    • Show details of a host

    • Create host(s)

    • Update a host

    • Delete host(s)

0.4.0-b1

New Features

  • Blazar gets to support before_end actions. Actions like snapshot can be taken at a specific time prior to the end of a lease. The time which triggers actions can be specified by the API parameter before_end_date and the default interval can be configured by a new configuration option minutes_before_end_lease in the [manager] section. The system default action for physical host plugin can be configured by a new configuration option before_end in the [physical:host] section. It can be also specified by a new API parameter before_end in a reservation. The value of this parameter can be snapshot, default, or blank. A system default action will be taken if default is specified or no before_end parameter included. If blank (“”) is explicitly specified, no action will be taken.

  • The update host API now allows new extra capabilities to be created on existing hosts, in addition to allowing values of existing keys to be modified. However, extra capabilities cannot yet be removed due to lack of API support. As a workaround, operators can delete hosts and recreate them.

  • The physical-host plugin has been changed to force-delete all instances on leased hosts at the end of a lease for preventing failures of other following leases.

  • The new instance reservation feature is available from the Pike release. This feature enables a user to reserve instance slots on hypervisors for future usage. A user creates a lease for an instance reservation prior to creating the instance(s), then a confirmed reservation ensures he/she can create their instances within the reservation period. For detailed usage instructions, please read the Blazar documentation. Known limitation: in the Pike release this feature does not yet support reservations with affinity=True. Use the host reservation feature instead.

  • The lease-update API supports update of reservation properties. e.g. min, max, hypervisor_properties and resource_properties for host reservation.

Upgrade Notes

  • The API parameter before_end_notification has been renamed before_end_date which is used for setting the time for triggering actions before the end of a lease.

  • The configuration option notify_hours_before_lease_end in the [manager] section has been removed. Use a new configuration option minutes_before_end_lease instead. The default value for the configuration option has been changed from 48 hours to 60 minutes.

  • The previous instance reservation plugin, named ‘basic.vm.plugin’ in blazar.conf, is completely removed from Blazar. Deployments including this plugin in blazar.conf must be updated by removing it from the plugins list. Otherwise, the blazar-manager service will fail to start with an exception about invalid plugin names.

Deprecation Notes

  • The on_start and the on_end configs for the physical-host plugin have been removed.

0.2.0

Known Issues

  • The instance reservation feature is not available in this release because it depends on Nova API extensions. Support for these extensions was completely removed from Nova in Newton (see Remove support for API extensions). Expect the instance reservation feature to be implemented differently in a future release.

Upgrade Notes

  • All entities in the ‘climate’ namespace, such as those used in policy.json and some configuration values, have moved to the ‘blazar’ namespace in the Ocata release. When upgrading Blazar, please replace all configuration values including the ‘climate’ string by their ‘blazar’ equivalent.

Deprecation Notes

  • The Blazar-specific Nova scheduler filter named ClimateFilter is now deprecated and will be removed in the next release. Please use BlazarFilter instead. This change is part of the transition from Climate (the old name of this project) to Blazar.

  • Commands which have ‘climate’ in their name are deprecated in Ocata. They will be completely removed in the Pike release. Instead of commands starting with ‘climate’, the Blazar project supports commands starting with ‘blazar’ from Ocata.