This allows users to query for resource properties of hosts,
allowing them to be used in creating leases more effectively. Two new
API endpoints are added for hosts, ``/properties`` and
``/properties/<property_name>``, which allow for listing available
properties, and updating a property respectively. Properties can be
listed with detail, showing possible values and visibility. Admins can
list public and private properties.
A new database table is added ``resource_properties``, which stores
property names and resource types. Resource specific property tables
(e.g. ``computehost_extra_capabilities``) entries store a foreign key to
``resource_properties``, rather than the capability name.
Implements blueprint resource-properties-discovery-api
Change-Id: Ib9f1140c44c5e4fbef6e019c48a842869368cb21
This change modifies the DB utility to fetch reservation allocations so
that a list of reservations is returned with host_ids as an attribute to
each reservation.
This allows the host plugin to include more information when listing
allocations, namely start and end dates. This can be used to see when
resources are available, and for the creation of a reservation calendar
(blueprint calendar-view).
Change-Id: I464898bdeda6b55a028c8a14a54eb137c92a83c1
Switch to openstackdocstheme 2.2.1 and reno 3.1.0 versions. Using
these versions will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering problems
Update Sphinx version as well.
Set openstackdocs_pdf_link to link to PDF file. Note that
the link to the published document only works on docs.openstack.org
where the PDF file is placed in the top-level html directory. The
site-preview places the PDF in a pdf directory.
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
openstackdocstheme renames some variables, so follow the renames
before the next release removes them. A couple of variables are also
not needed anymore, remove them.
See also
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html
Change-Id: Ib2fc9304a6db9f01eb6d0eb82363906fd322612f
This patch adds global_request_id to the constructor for nova client,
keystone client, neutron client and placement client which will pass the
global_request_id to these respective services on all API calls.
Supporting global_request_id makes debugging easier when requests reach
many different OpenStack services. The blazar global_request_id will be
sent to these services in the request header like below and it will be
available with context.global_request_id:
-H "X-OpenStack-Request-ID: req-1a9b7b24-02ed-4400-bcc3-cc1bcbb59147"
Sample log output of neutron service for ``POST v1/floatingips`` API
which logs global request ID `req-e19f8f4f-40e7-441e-b776-7b43ed15c7dd`
is shown at: http://paste.openstack.org/show/753807
Oslo spec I65de8261746b25d45e105394f4eeb95b9cb3bd42
Change-Id: I5bb3631c4fb178293ee8eefbe1aa8b819a196a9f
'x-openstack-request-id' is the common header name for request ID
which is implemented in most of the OpenStack services. Using the
oslo middleware `request_id` middleware is a convenient way to
generate request ID and also include it in the response.
The request ID will be generated by the oslo middleware and is
inserted into the request environment. On the response end, the
middleware is again used, this time to attach the
'x-openstack-request-id' header, using the value of the generated
request ID.
Sample log output of blazar-api service for ``GET v1/os-hosts`` API
which logs local request ID `req-de45521c-2a04-4e7d-809a-960e782eb1e7`
is shown below:
http://paste.openstack.org/show/753805/
Note: For v2 apis, the request_id is not returned in response header
but it will be logged in logs.
APIImpact:
responses of the API will include 'x-openstack-request-id' header.
Implements: blueprint oslo-middleware-request-id
Change-Id: I437f783787514ff1add2d7f0059cb27addd12c3e
Some options are now automatically configured by the version 1.20:
- project
- html_last_updated_fmt
- latex_engine
- latex_elements
- version
- release.
Change-Id: Ia4386840658666079f4902fc72bd6772b42f00dc
If user passes invalid affinity values (abc, 2), the lease is getting
created/updated successfully.
This patch will return 400 error if user passes invalid affinity values
to lease create and update APIs.
APIImpact:
1)Return 400 instead of 201 when lease is created with invalid affinity
for resource_type 'virtual:instance'.
2)Return 400 instead of 200 when lease is updated with invalid affinity
for resource_type 'virtual:instance'.
Change-Id: I3170a0957de43fd2b7bcd32eca375da2d1f17360
Closes-Bug: #1821576
Lease is getting created and updated for resource_type virtual:instance
with amount=0.
This patch doesn't allow creation and update of lease with amount=0, it
will raise 400 BadRequest.
Lease creation for resource_type physical:host with min=0 or max=0
raises 500 Internal Server Error and lease is updated for resource_type
physical:host with min=0 or max=0.
This patch doesn't allow creation and update of lease with min=0 or
max=0, it will raise 400 BadRequest.
APIImpact:
1)Return 400 instead of 201 when lease is created with amount=0 for
resource_type 'virtual:instance'.
2)Return 400 instead of 500 when lease is created with min=0 or max=0
for resource_type 'physical:host'.
3)Return 400 instead of 200 when lease is updated with amount=0 for
resource_type 'virtual:instance'.
4)Return 400 instead of 200 when lease is updated with min=0 or max=0
for resource_type 'physical:host'.
Closes-Bug: #1807101
Change-Id: I70e35ac7a524afb04077da5978c7563dec120639
The List and Get Allocation API allows cloud admin to query with
reservation_id in their request. When the parameter is specified in API
requests, the API returns allocations related to the reservation.
Partially Implements: blueprint resource-allocation-api
Change-Id: I87ed410c23f04a17f6c1deeb9ad1e4ab0756a549
The List and Get Allocations API allows admins to query with lease_id.
When the query key is specified in API requests, the two APIs only
returns allocations related to the lease ID.
Partially Implements: blueprint resource-allocation-api
Change-Id: Ibf2c92d42dbe3fb055a78028967e202327cfee34
This patch exposes List and Get Reservation Allocations API to cloud
admins by default.
Partially Implements: blueprint resource-allocation-api
Change-Id: Ib8aa479b2b297b4564f734d07a25ca2637a56f49
Blazar returned 202 (Accepted) for POST and PUT methods. However, the
POST method should return 201 (Created) because Blazar ensures that a
new host or a new lease is created before responding. Similarly, the PUT
method should return 200 (OK) since Blazar ensures that the resource is
updated properly.
This patch also fixes the status code documented in the API Reference
for DELETE requests, which was wrongly described as 200 (OK) instead of
204 (No Content). The release note is submitted in a separate patch.
Change-Id: Ia5afd12552e4c9169ebe35324d5a5b4495359b63
This patch adds a 'resource_properties' key for instance reservation as
a required parameter. If a user specifies the key when they create
instance reservations, Blazar picks up hypervisors that match the key
for the reservation.
Partially Implements: blueprint flavors-extra-specs
Change-Id: Ia8877c667116739d75381776555f91e529c1c21d
Pierre Riteau