Rocky Series Release Notes

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 infomation, 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.

  • All climate namespace is removed in Rocky release.