Since cellsv2 has required host mappings to be present, we have lost
our automatic host registration behavior. This is a conscious choice,
given that we do not want to have upcalls from the cells to the API
database. This adds a periodic task to have the scheduler do the
discovery routine, which for small deployments may be an acceptable
amount of background overhead in exchange for the automatic behavior.
There is also probably some amount of performance improvement that
can be added to the host discovery routine to make it less of an
issue. However, just generalizing the existing routine and letting
it run periodically gives us some coverage, given where we are in
the current cycle.
Related to blueprint cells-scheduler-integration
Change-Id: Iab5f172cdef35645bae56b9b384e032f3160e826
The docs for this command were woefully out of date. This
change clarifies the wording since we're really upgrading
the schema in the database, not "synchronizing" it even
though that's the name of the command - the migration scripts
run the 'upgrade' method only. Also, it was saying this was
how you created the main database, which is totally wrong
since this command doesn't create the database. The deployer
creates the database, this command migrates the schema on that
database.
Then I also added the arguments along with a description of each
and noted that this will by default upgrade the cell0 schema.
Change-Id: I3d40cb32c325bc3f665e727b921082efba043192
This is just a simple change that provides a references section
for setting up cells v2 and points to the nova-manage cell_v2
man pages.
Change-Id: I94d3de97f4ff2120e250ac40ac82c31372d90a2b
There are two changes here:
1. Removes the mention of the message queue since the cell0
mapping has a transport_url but it's effectively none meaning
we don't use RPC for accessing cell0 objects.
2. Adds boilerplate wording on the config option used to determine
the database connection if the --database_connection argument
is not specified. This was particularly confusing at one point
because it originally started out as the CONF.api_database.connection
but we changed that mid-cycle in Ocata since the schema for cell0
is the cell (nova) DB, not the nova_api DB.
Change-Id: Ie869f8565460600da767d99e9e397abc5e8bf0e0
This removes a couple short circuits around instance cell mapping,
which were in place for pre-cellsv2 code. Now, they defeat some of
our atomic logic around what should be done in and around deletes.
These were TODOs to remove once people had to be on cellsv2, which
is now the case.
Note that the api samples tests were depending on these in order to
work at all (which is a good demonstration of why they need to
be removed). This patch also extends the SingleCellSimple fixture
with a couple more mocks to make them happily take the same path
as the rest of the code. Since the default in that fixture is
now to make instances look mapped all the time, we also need a flag
so the tests that check for yet-to-be-mapped instances can still
function.
Related-Bug: #1660878
Change-Id: I7eb4b41fd2f33e8a63e329adbafc47d149e31552
There was a very subtle yet busted 'return' statement in the
except block when cleaning up an instance in the case that the
build request was already deleted. This return statement would
short-circuit the for loop it's in such that no other build
requests in the loop would get processed (so those instances
wouldn't get built).
This was probably missed because of how large the method is so
that when you're looking at that cleanup code, it's easy to miss
that you're in a for loop.
This change moves the build request cleanup block into a private
method so it's more self-contained, and fixes the issue with the
return statement by changing it to a 'continue' statement.
An existing test that deals with multiple instances already is
updated to show the bug and the fix (and also cleaned up a bit
in the process to avoid lots of copy/paste).
Change-Id: I399023ea705c514c33d07cc3613d79744cbf7a07
Closes-Bug: #1661024
The ResourceProviderList query use groupby without all grouped columns.
This works on mysql with unpredicable result, but don't for other RDBMS.
For example, postgresql gating jobs dsvm that use nova are currently
broken.
This change removes the unused consumer_id on first query,
and uses the primary key 'id' instead of 'uuid' the second groupby.
(Because groupby in postgresql requires a PK or all non-primary columns)
The fix is tested by gate-ceilometer-dsvm-tempest-plugin-postgresql-ubuntu-xenial job
here: https://review.openstack.org/#/c/427668/
closes-bug: #1660959
Change-Id: I6cc93ba0dd569d56696c9210d38dd2d77b4157c1
Recent work on cells v2 has us reading instances from compute cells
via target_cell, but that breaks the existing behavior of cells v1
because of the syncing between API cell and compute cells. When
state changes are effected in the API cell, there is a slight delay
before they are reflected in the compute cell. So, reading from the
compute cell instead of the API cell results in behavior changes.
This adds a conditional in compute/api get_all to read instances
from the API cell if cells v1 is enabled. We are already doing this
for compute/api get, and get_all was missed.
Closes-Bug: #1660747
Change-Id: I7df5c4616ef386216c7bd7efea2be68173c61be0
The help message for the --verbose option claims map_cell_and_hosts
both returns and prints the cell uuid, when really it just prints
the cell uuid and returns 0 on success.
Change-Id: Ia14f2250fedf0bd6456b0088b962460b999b9f8d
When the resource tracker creates a new resource provider it sets
the generation to 1. This is wrong, because on the server side the
default value for a generation, and thus the generation for a new
provider is 0. This fixes that situation and thus avoids causing the
first inventory write operation from the resource tracker to the
placement API being a 409 conflict.
Change-Id: Iaa9e786f33049799678f21b5dfaac417c6601ac8
Closes-Bug: #1660682
In 'd4e6bd8', and later refined in 'ec6ed24c', an issue with the the
Quobyte CI was resolved by ensuring that the 'console.log' file is
always created, even when libvirt's 'dynamic_ownership' config option
is set to '0'. However, attempting to take ownership of this file can
cause issues when 'dynamic_ownership' is set to '1' and a user attempts
to reschedule an instance to a host where it was previously located. In
this case, the permissions on the file have already been co-opted by
libvirt, and attempting to change them results in an IOError.
The easiest fix for this is to simply ignore the IOError, as the file
already exists and libvirt has set correct permissions already. This is
what do here. A longer term fix would be to avoid changing the
permissions only for the offending Quobytes block devices, but this is
likely not backportable and will be done in a follow-up fix.
Change-Id: I353afd57be207330757580447a1b606c7b9b7c09
Partial-bug: #1634282
Related-bug: #1597644
Related-bug: #1609298
Document the `nova-manage cell_v2 delete_cell` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I280b87ad38feeaa68728f51c78b1c6a0dc895ca7
Document the `nova-manage cell_v2 list_cells` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I0cd0c3d8c6cd0229a62b3eaf18679d4931c6e4eb
Document the `nova-manage cell_v2 discover_hosts` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I7ce9a93384741e42f409324cf0ee3cb1fc4c6a67
Document the `nova-manage cell_v2 create_cell` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: Ic9ddef319aaf8a377d733633cc279a0fc1558cb2
Document the `nova-manage cell_v2 verify_instance` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: Id243299bdf0f115e86200cee38634791ea359b2a
Document the `nova-manage cell_v2 map_cell_and_hosts` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I4ed1e77f100e9d90d6a1ebd5e20bdd1f1ff5ce6e
In the context of device tagging, bugs have caused the tag attribute
to disappear starting with version 2.33 for block_devices and starting
with version 2.37 for network interfaces. In other words, block
devices could only be tagged in 2.32 and network interfaces between
2.32 and 2.36 inclusively.
This patch documents this behaviour in api-ref and introduces
microversion 2.42, which re-adds the tag in all the right places.
Change-Id: Ia0869dc6f7f5bd347ccbd0930d1d668d37695a22
Closes-bug: 1658571
Implements: blueprint fix-tag-attribute-disappearing
Jenkins