Bug Fixes¶

• Updating a lease with invalid parameters (for example, specifying aninvalid date range) now has no effect on the lease, where previously thiswould cause the lease to be set to ERROR status. For more details, seebug1786031.

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

• Fixes failure to update reservations when theresource_type parameteris not provided in the API request. For more details, seebug 1957761.

• Fixes result of the List Allocations API for reservations with multiplephysical hosts. For more details, seebug 1958307.

Upgrade Notes¶

• The default value of the[oslo_policy]/policy_file configuration optionhas been changed frompolicy.json topolicy.yaml. Operators usingcustomized or previously generated static policy JSON files (which are notneeded by default) should generate new policy files or convert them to YAMLformat. Use theoslopolicy-convert-json-to-yamltool to convert a policy file from JSON to YAML in a backward-compatibleway.

Deprecation Notes¶

• Use of JSON-formatted policy files was deprecated by theoslo.policylibrary during the Victoria development cycle. As a result, thisdeprecation is being noted in the Wallaby cycle with an anticipated futureremoval of support byoslo.policy. As such operators will need toconvert to YAML-formatted policy files. Please see the upgrade notes fordetails on migration of any custom policy files.

Bug Fixes¶

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

Bug Fixes¶

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

Upgrade Notes¶

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

Bug Fixes¶

• Updates the on_start failure handlers to look up the freepool aggregate byID, not by name, when moving hosts back to the freepool. Fixes issue wherehosts wind up without any aggregate during lease start failure. For moredetails, seebug 1847821.

New Features¶

• Blazar now supports API microversions. All API changes should be made whilekeeping backward compatibility. The API version is specified in theOpenStack-API-Version HTTP header. To view the mininum and maximumsupported 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.Theamount of reserved floating IPs can be updated; however, updatingnetwork_id is denied andrequired_floatingips can only be changedto an empty list.

• Adds support forglobal_request_id to theRequestId middleware. Aninbound header ofX-OpenStack-Request-ID is accepted as long as it isof the formatreq-$uuid, and made available to oslo.context. Thisallows for cross-project request ID tracking. By default, global requestIDs will not appear in the Blazar service logs. Operators need to addglobal_request_id in thelogging_context_format_string configurationoption.

• Blazar now uses oslo.middleware for request_id processing which will nowreturn a newX-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 tracingand it is configurable via the[DEFAULT]/logging_context_format_stringoption.

Bug Fixes¶

• Fixes placement operations in multi-region deployments.

Other Notes¶

• The specifications for Blazar have been moved from openstack/blazar totheir own repository, openstack/blazar-specs. Specs are now available athttps://specs.openstack.org/openstack/blazar-specs/.

Prelude¶

Added new toolblazar-statusupgradecheck.

New Features¶

• New framework forblazar-statusupgradecheck command is added.This framework allows adding various checks which can be run before aBlazar upgrade to ensure if the upgrade can be performed safely.

• Added a new resource plugin supporting floating IPs. This plugin enablesusers to reserve floating IPs from Neutron. To try the plugin, addvirtual:floatingip to the[manager]/plugins configuration option inblazar.conf. For the API schema, see details of the APIs in theLeaseAPI reference andFloating 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, andthe Update Lease API is not implemented. Floating IP reservation will befully completed in the next release.

• For instance reservation, the reservation parameteraffinity nowsupportsTrue andNone and defaults toNone

  • affinity=True

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

  • affinity=False

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

  • affinity=None (default)

    • The picked up hosts can be different or same.

  AggregateInstanceExtraSpecsFilter,AggregateMultiTenancyIsolation,orServerGroupAffinityFilte is not needed any more for blazar’sinstance reservation.

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

Upgrade Notes¶

• Operator can now use new CLI toolblazar-statusupgradecheckto check if Blazar deployment can be safely upgraded fromN-1 to N release.

Bug Fixes¶

• Fixes an issue wherein increasing the number of hosts of an active hostreservation 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 areservation, any host previously moved into the same aggregate is now movedback to the freepool. This helps to prevent failures to start future leasesallocating the same hosts.

• Blazar now prevents leases from being deleted while their start_lease orend_lease events are in progress, to avoid concurrently accessing sharedobjects. For more details, seebug 1791741.

New Features¶

• A time margin for cleaning up resources between the end of a lease and thestart of the next lease is introduced. Leases are allocated to resourcesonly if they have enough spare time for cleaning up before and after thelease. Note that this cleaning time is not included in the lease time, butis taken into account when looking for available resources. The length ofcleaning time can be configured by the configuration optioncleaning_time in the [DEFAULT] section. The default value for thisoption is0, in which case the behavior is the same as previousreleases.

• 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 canspecify the availability zone information by hypervisor_properties in thehost reservation and by resource_properties in the instance reservation.

• Resource monitoring supports periodic healing from the Rocky release. Itonly heals reservations starting within a configurable time window in orderto avoid unnecessary reservation healing, e.g. when resources becomeavailable again at a later date. The interval is defined with the[physical:host]/healing_interval configuration option. The defaultvalue is 60 minutes. For more details, please see theResourceMonitoring section in the Blazar documentation. The previous mode ofoperation, which heals all reservations regardless of their start date, canbe used by setting[physical:host]/healing_interval to0.

• Default policy for API access control has been moved from a file, e.g.policy.json, into codebase. Policy is basically defined in codebase butable to be changed by a policy file. Seethe policy configuration guidein detail.

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

Known Issues¶

• When the update lease API returns any error regardless of the reason, thelease status goes into ERROR. If the reason is wrong input, e.g. invalidformat or not enough hosts available, updating the lease again with correctinformation will fix the ERROR status. For more details, seebug 1786031.

Upgrade Notes¶

• The availability zone information is stored only when cloud operators adda 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 andits owner are allowed to call the API until Queens. From Rocky release,only the admin is allowed to call the API.

Bug Fixes¶

• In theBlazar 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 notreflected in Blazar. This was because internally in the Blazar serviceos_admin_user_domain_name was used wrongly for both the project domainname and the user domain name.

  This didn’t affect operators who set neither of the values explicitly inthe configuration file, because the default values of the two options areboth set toDefault. This release fixes the bug for operators who seteither of the values explicitly.

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

  • Requesting instance reservation withaffinity=True: 500 to 400

    • Instance reservation only accepts affinity = False until the pluginimplements theSupport no affinity rule blueprint.The Create Lease API and the Update Lease API now return 400 BadRequest instead of 500 Internal Server Error when affinity = Trueis 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 isearlier than start_date, which was causing lease errors because ofinvalid status change. From the Rocky release, the API checks theordering of the two events and returns an appropriate response statuscode.

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

    • 403 response code means an API request is Not Authorized. When theordering of the two is invalid, the response status code is now 400 BadRequest, since the request is authorized but has an invalid requestbody.

  • 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 of64 characters. When a request body includes an extra capability longerthan 64 characters, the response status code of the Create Host API andthe Update Host API is now 400 Bad Request instead of 500Internal Server Error.

  • Creating a new host/lease: 202 to 201

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

  • Updating a host/lease: 202 to 200

    • The Update Host API and the Update Lease API now return 200 OK insteadof 202 Accepted, since Blazar ensures that a host/lease is updatedbefore 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”, otherwiseit raises 400 Bad Request instead of 500 Internal Server Error.

Other Notes¶

• The DevStack plugin now supports installing blazar-dashboard when bothblazar and horizon services are enabled inlocal.conf.

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

• All climate namespace is removed in Rocky release.

New Features¶

• The resource monitoring feature is available from this release.This feature monitors states of resources in the freepool. If any failureis detected, reservations which suffer from the failure are healed.New flags have been introduced into leases and reservations to indicatehealth of reserved resources.Resource monitor is plugable and the compute host resource monitor iscurrently supported. Seeresource 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 isautomatically updated fromNone by an Alembic database migration script.Seestate machine documentation for more details.

New Features¶

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

  • Show a list of hosts

  • Show details of a host

  • Create host(s)

  • Update a host

  • Delete host(s)

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 parameterbefore_end_date and the default interval can be configured by a new configuration optionminutes_before_end_lease in the [manager] section. The system default action for physical host plugin can be configured by a new configuration optionbefore_end in the [physical:host] section. It can be also specified by a new API parameterbefore_end in a reservation. The value of this parameter can besnapshot,default, or blank. A system default action will be taken ifdefault is specified or nobefore_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 onexisting hosts, in addition to allowing values of existing keys to bemodified. However, extra capabilities cannot yet be removed due to lack ofAPI support. As a workaround, operators can delete hosts and recreate them.

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

• The new instance reservation feature is available from the Pike release.This feature enables a user to reserve instance slots on hypervisors forfuture usage. A user creates a lease for an instance reservation prior tocreating the instance(s), then a confirmed reservation ensures he/shecan create their instances within the reservation period. For detailedusage instructions, please read the Blazar documentation. Known limitation:in the Pike release this feature does not yet support reservations withaffinity=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 parameterbefore_end_notification has been renamedbefore_end_date which is used for setting the time for triggering actions before the end of a lease.

• The configuration optionnotify_hours_before_lease_end in the [manager] section has been removed. Use a new configuration optionminutes_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’ inblazar.conf, is completely removed from Blazar. Deployments includingthis plugin in blazar.conf must be updated by removing it from theplugins list. Otherwise, the blazar-manager service will fail to startwith an exception about invalid plugin names.

Deprecation Notes¶

• Theon_start and theon_end configs for the physical-host plugin havebeen removed.

Known Issues¶

• The instance reservation feature is not available in this release becauseit depends on Nova API extensions. Support for these extensions wascompletely removed from Nova in Newton(seeRemove support for API extensions).Expect the instance reservation feature to be implemented differently in afuture release.

Upgrade Notes¶

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

Deprecation Notes¶

• The Blazar-specific Nova scheduler filter namedClimateFilter is nowdeprecated and will be removed in the next release. Please useBlazarFilter 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. Theywill be completely removed in the Pike release. Instead of commandsstarting with ‘climate’, the Blazar project supports commands starting with‘blazar’ from Ocata.