Creation of list here is useless. As I understand such
'cycle' was added just to have less number of code.
But creation of this list allocates memory for it.
Change-Id: Ib822fcc5ebf2ece987736ae48a51df5b6f5d0fd4
This removes some references to "online schema migrations", as well
as some references to in-progress things that have been (long since)
completed. It also clarifies some of the upgrade steps, and unifies
the notion of "offline" and "live" upgrades, calling out only a couple
places where the process differs.
This came from me explaining the document to someone and calling out
things that were no longer accurate.
Change-Id: Iec1d73c3fd0038d9bca7e7fa746caad06c329ed3
While debugging resource tracking/placement issues with resource
providers it'd be useful to know the request ID from the placement
API for debugging requests in those logs. These changes add the
request id to those log messages that might be created while getting
or creating a resource provider.
Change-Id: I412d8ef63eb0ecb32b8316826498cfc00e6014cd
While debugging resource tracking/placement issues with resource
providers it'd be useful to know the request ID from the placement
API for debugging requests in those logs. The changes adds the
request id to those log messages that might be created while getting
aggregates for a resource provider.
Related-Bug: #1652099
Change-Id: I0e44c439fd4c9999d6dac5054e24503f925df1ed
While debugging resource tracking/placement issues with resource
providers it'd be useful to know the request ID from the placement
API for debugging requests in those logs.
Change-Id: I36db3cf21e5764830c6af4d160698979dbb02fab
Related-Bug: #1652099
While debugging resource tracking/placement issues with resource
providers it'd be useful to know the request ID from the
placement API for debugging requests in those logs, at least
until nova-compute is passing it's request ID header into the
placement API. And it'd also be useful to know the generated
request body when making the failed inventory update request.
Change-Id: Ia8ee36ab0e79dfc2a178f2d354288b13d48bccdb
Related-Bug: #1652099
Currently when a compute node is deleted, its record in the cell DB is
deleted, but its representation as a resource provider in the placement
service remains, along with any inventory and allocations. This could
cause the placement engine to return that provider record, even though
the compute node no longer exists. And since the periodic "healing" by
the resource tracker only updates compute node resources for records in
the compute_nodes table, these old records are never removed.
This patch adds a call to delete the resource provider when the compute
node is deleted. It also adds a method to the scheduler report client
to make these calls to the placement API.
Partial-Bug: #1661258
Closes-Bug: #1661014
Change-Id: I6098d186d05ff8b9a568e23f860295a7bc2e6447
Add a release note for the filter/sort whitelist.
Part of blueprint add-whitelist-for-server-list-filter-sort-parameters
Change-Id: I0369407aced56384783b7a8bb10e06e80530854f
Co-Authored-By: ghanshyam <ghanshyammann@gmail.com>
Co-Authored-By: Alex Xu <hejie.xu@intel.com>
Swap is in MB, but allocations for disk are in GB.
We totally should claim disk in GB, for now lets just round up the swap
allocation to the next GB. While this is wasteful, its the only safe
answer to ensure you don't over commit resources on the node.
Updated the test so the swap is 1023MB, after rounding up this should
claim the same 1GB extra space for swap.
Closes-Bug: #1659266
Change-Id: If50eab870b2c50f4055668143780574e1350a438
People are easily confused into thinking that for cells v2
they need to configure things in the [cells] group in
nova.conf, but the cells options are strictly for cells v1
functionality, which we don't want people using anymore.
This change adds some wording to those options to make it
clear that they are for cells v1 and that is not a
recommended way to deploy Nova.
Change-Id: Ib1f0caf956d0bbb76d2e5a8e6d5ce7de12e240b2
We were reporting reserved_host_disk_mb as GB not KB.
This created this log message:
Invalid inventory for 'DISK_GB' on resource provider <uuid>.
The reserved value is greater than or equal to total.
This corrects the reporting of reserved_host_disk_mb to the placement
API when updating the compute node inventory.
Closes-Bug: #1661243
Change-Id: I5573c82eb99cde13c407c8d6a06ecb04165ab9c5
While adding the json schema for servers filter query,
we added 'accessIPv4' and 'accessIPv6' as allowed params
but they do not match with what DB has. It is 'access_ip_v4'
and 'access_ip_v6' in DB.
This makes 'access_ip_v4' and 'access_ip_v6' filter stop working.
The schema should be fixed accordingly to allow the 'access_ip_v4'
and 'access_ip_v6' as valid filter.
'accessIPv4' and 'accessIPv6' are something the API accepts
and returns and internally API layer translate those param
to their respective field('access_ip_v4' and 'access_ip_v6')
present in DB.
So user does not know anything about 'access_ip_v4' and
'access_ip_v6'. They are not in API representation actually.
Later list filter and sort param should be same as field return
in GET or accepted in POST/PUT which are 'accessIPv4' and 'accessIPv6'.
But that is something new attribute support in filter and can be
done later after more discussion.
Change-Id: Idc12de0062d298259e25c8b4c0dde889054a9ae5
Closes-Bug: #1661195
This just adds some more detailed docs for upgrading
to Ocata and notable things for the Placement service
and related components as part of that upgrade.
The Ocata release notes will have some of this
information too, but I think it's good to also have
a single place for some of this, like an install/upgrade
guide for Placement.
Change-Id: Id33b9c852bb36ae80a6f29ae33d963a78cbff193
Depends-On: Ie12acb76ec5affba536c3c45fbb6de35d64aea1b
Jenkins