The nova.objects.base.obj_equal_prims returns True or False.
It does not assert anything.
So the return value should be asserted in tests.
Add assertTrue where the nova.objects.base.obj_equal_prims is called.
Change-Id: I49460ec3b572ee14b32229e771a5499ff91e8722
Closes-Bug: #1839853
This migration was added in Ocata and backported to Newton in change
I8a05ee01ec7f6a6f88b896f78414fb5487e0071e to deal with Mitaka-era
build_requests records that would not have an instance_uuid value
and thus raise a ValueError in BuildRequest._from_db_object (because
BuildRequest.instance_uuid is not nullable).
This is essentially a revert of that change now since operators
have had long enough to run the migration. If anyone were to skip
level upgrade from Mitaka to Train (which we don't support, we require
you to roll through), and hit an issue with this they could simply
execute this on their nova_api DB:
DELETE FROM build_requests WHERE instance_uuid IS NULL;
Change-Id: Ie9593657544b7aef1fd7a5c8f01e30e09e3fcce6
When listing "real" (already in cell) instances e.g. from
nova_cell1.instances table, a marker option means "start after the
instance with marker".
For VMs:
| uuid | name |
| 1 | vm1 |
| 2 | vm2 |
"openstack server list --marker 1" returns vm2 only.
But for VMs from nova_api.build_requests table it's different.
For VMs:
| uuid | name |
| 1 | vm1 |
| 2 | vm2 |
"openstack server list --marker 1" returns both vm1 and vm2.
This patch excludes instance with marker from listing for
instances from build_requests table.
Closes-Bug: #1808286
Change-Id: I5165b69f956fbf1904112a742698b2739f747e72
For some reason, probably because build requests are meant to be short lived
and we don't get a lot of bugs about paging misbehavior, when paging instances
with a marker, we didn't raise MarkerNotFound if we didn't find the marker in
the list of build requests. Doing so would match what we do when paging over
cells and listing instances using a marker. Once we find the marker, be that
in build_requests, or one of the cells, we need to set the marker to None to
stop looking for it elsewhere if we have more space to fill our limit.
For example, see change I8a957bebfcecd6ac712103c346e028d80f1ecd7c.
This patch fixes the issue by raising MarkerNotFound from BuildRequestList
get_by_filters if there is a marker and we didn't find a build request for
it. The compute API get_all() method handles that as normal and continues
looking for the marker in one of the cells.
Change-Id: I1aa3ca6cc70cef65d24dec1e7db9491c9b73f7ab
Closes-Bug: #1737856
This is the second patch of the series,
this patch adds tags to build_request
object.
Change-Id: I1121eaf24856dcb74f07c224531a821b3cdc46fc
Part of blueprint support-tag-instance-when-boot
This exhibits the failure reported in bug 1633734 when upgrading
from mitaka to newton with some bad build request records that
weren't cleaned up, and were created before API DB migration
013_build_request_extended_attrs when we didn't have the
instance_uuid or instance records in the database.
After 013_build_request_extended_attrs and the object change to
BuildRequest in a5d3b57c3d if we try
loading up a 'dirty' build request DB record without the
instance_uuid it fails with a ValueError, as shown in the functional
test in this change.
This also provides an online data migration (which will be backported
to Newton for upgrades from Mitaka) that will query the API DB for
build requests where instance_uuid=NULL and delete them.
Change-Id: I8a05ee01ec7f6a6f88b896f78414fb5487e0071e
Related-Bug: #1633734
There are some cases where the instance is still waiting to be scheduled and
consequently there is still a BuildRequest object where we would also like to
update the instance attributes, like the display name.
In that case, we need to update the nested instance field from the BuildRequest
instead of trying to update the instance object itself, which could be located
in a child cell.
Change-Id: I97cd6dbae10ca1a29f646b0b25bc08edd699edca
Closes-Bug: #1620248
The BuildRequestList object can be used to fetch a list of pre-scheduled
instances which have not been written to an instance table yet. The
get_by_filters method emulates the behavior of Instance.get_by_filters
and returns a BuildRequestList object with the contained BuildRequest
objects sorted and filtered on the Instance object contained within.
Change-Id: If3638caba2c12d4c087a854bd8cbf4f79ef9652d
Partially-implements: bp add-buildrequest-obj
Partially-implements: bp cells-scheduling-interaction
This is preliminary work towards moving instance creation until after
scheduling. In order to do that we still need the ability to honor an
instance show request. This does a lookup to determine if an instance is
in a cell and if not it synthesizes an instance from the BuildRequest
object that has been stored.
If the instance is not mapped then the deployment has not migrated to
their first cell yet and the instance lookup proceeds as usual.
Until instance creation is moved to after scheduling this is mostly a
noop.
Honoring the instance list command will come later.
Change-Id: Ib984c30543acb3ca9cb95fb53d44d9ded0f5a5c8
Partially-implements: bp add-buildrequest-obj
Partially-implements: bp cells-scheduling-interaction
Due to the os-extended-volumes API it is necessary to be able to
retrieve block device mapping info for an instance at any time. In order
to do so it needs to be stored with the build request.
This also makes it available during instance deletion where it may be
useful to look up whether delete_on_termination is set on a bdm so that
it can be cleaned up.
Change-Id: Ib774a43e49b7153b3f7b099a59483c62003ee7a8
Partially-Implements: bp add-buildrequest-obj
Loading the InstanceDeviceMetadata object into the
instance will avoid the need to make multiple calls
to the db from the metadata service.
Partially implements blueprint virt-device-role-tagging
Change-Id: Iea73c26e48d02c9fda9426c8603d1627c0e8e692
After an instance has been scheduled to a cell and mapped to the
instance table there the BuildRequest for it will be destroyed. An
instance delete that occurs before that remapping has happened will also
destroy the BuildRequest.
In order to know that a delete has happened, and stop the build, the
destroy method should raise an exception if it is already deleted.
Change-Id: Ib86ac14e2bd933bb9e76ea86b2a1ec4f40d204a3
Now that there's a serialized instance object on the BuildRequest object
and in the build_requests table a lot of fields/columns are no longer
necessary. To prepare for removal of the columns from the db at a later
time references to them have been removed. This starts a deprecation
timer so that they can be removed in Ocata at the earliest.
Note that the BuildRequest object was never passed over the wire, and is
just created and immediately destroyed at this point so there is no need
to handle backwards compatibility for these changes.
Change-Id: Ie86ba66d5f73c153b68bef83661d4c8bdb0ae9dc
It turns out that BuildRequest was going to need to copy quite a bit of
the Instance fields and was starting to look very similar. Instead of
continuing to add fields to BuildRequest let's just store a serialized
Instance in there so everything is available.
Note that the BuildRequest object version is not being bumped because
this object is not yet passed over the wire anywhere or looked up
anywhere, so there are no backwards compatibility concerns.
Partially-implements: bp add-buildrequest-obj
Change-Id: I63023915b5b7907949e55d6fd2693fcbc7777511
This is the beginning of a poison fixture for tests that don't use
the database. If they do, we interrupt them deep in oslo_db, log a
warning, and return a MagicMock. This keeps them from breaking
global database state, but doesn't actually poison them. This should
be followed-up with a patch to raise an exception, and fix the rest
of the tests that depend on the broken behavior.
Since some tests claim to not be DB test, but use the fixture
themselves anyway, this adds a USES_DB_SELF flag to help gate
the application of the poison.
Change-Id: If071a12a33aad86e918a9f441a246a930e921c8d
The BuildRequest object represents a boot request before an instance has
been created and written to the database. It will be required to respond
to API requests to list/show an instance in cellsv2 where the instance
is not written to the database immediately. An upcoming change will
modify the boot process to defer instance creation until after
scheduling has picked a cell/host and having this BuildRequest object is
a prerequisite for that work.
Change-Id: Ie9307388c2e068229177bcc4690cb834028c1481
Partially-implements: bp cells-scheduling-interaction
Takashi NATSUME