Cold migrate and resize can now get the Spec object and pass it
down the wire to the conductor so that it could use it for the
move.
Partially-Implements: blueprint check-destination-on-migrations-newton
Co-Authored-By: Pawel Koniszewski <pawel.koniszewski@intel.com>
Change-Id: Ic3968721d257a167f3f946e5387cd227a7eeec6c
In Mitaka, we began to create and persist a RequestSpec object every time
a new instance was requested. Given that instances that were created before
that commit do not have a related RequestSpec, we needed to check
every time in the conductor methods whether the instance had a request spec
associated with it.
Now that we are in Newton, we can provide an online data migration script
that iterates over all the instances (using a marker), verify if the
RequestSpec object is created, and if not, try to persist into that object
the legacy fields we already know.
The marker uses the request_specs table for persisting itself, and
yes this is a hack, but that's the only solution we agreed for making sure
we were not looping every time on all the instances (which would be a
performance problem). When we finish looping over the instances, we
keep that marker so that the next call to that migration script
would not again iterate over all the instances (using the limit).
Change-Id: I61b9b50436d8bdb8ff06259cc2f876502d688b91
Partially-Implements: blueprint check-destination-on-migrations-newton
TestNeutronSecurityGroupsOutputTest and BootFromVolumeTest were tests
only for legacy v2 API code, and v2.1 API were not tested on the same
test cases. This patch makes the tests work for v2.1 API code for the
test coverage.
In addition, this patch changes a request body of BootFromVolumeTest
because v2.1 API validation detected the bugs of the body like the
following:
* Invalid input for field/attribute volume_id. Value: 1. u'1' is not a 'uuid'"
* Additional properties are not allowed (u'virtual' was unexpected)
Change-Id: I9c2a53679ed6a097b062ba542dddd85a42c9964f
This adds message queue connection information to the RequestContext
which can be used by nova-api to communicate with a targeted cell
message queue with each query.
A function 'get_cell_client' can be called in rpc functions to enable them
to use message queue transport information from a RequestContext. The
function creates a rpc client object dynamically if message queue
connection information is found in the RequestContext and falls back on
the default rpc client.
Example usage:
def get_cell_client(self, context):
return rpc.get_cell_client(context, self.client)
def build_and_run_instances(self, ctxt, instance, host, image, ...)
cctxt = self.get_cell_client(ctxt).prepare(...)
cctxt.cast(...)
Implements blueprint cells-mq-connection-switching
Change-Id: Idef670d5b73c9cef8501a0593eccd785b708bd2b
os-api-ref is released on pypi now, so we can move to using it instead
of our in tree version. All future extension fixes will happen over
there instead of here.
Change-Id: Iee4b9c94b8b66a5b0481dd0b15beda03328c4f31
Depends-On: I0e615d36a2e5a8fa0d83f20bdcc2c33ad868ebd5
The config options of the "nova.conf" section "database" and
"api_database" got moved to the new central location
"nova/conf/database.py". Also the database related options which are
in DEFAULT section.
Follow up changes will improve the help texts.
bp centralize-config-options-newton
Change-Id: Iaba9b49490fea4950bb25eed3ba1252db206f3c9
There were a few comments and suggestions for improvements in the
wording for the recent series of patches that added improved help text
to the API config options. Rather than hold up those patches, this
follow-up patch cleans up those issues.
Blueprint centralize-config-options-newton
Change-Id: I512ea8c2be383e1abef7580e32deaa40e2c76c60
This reorder's parameters.yaml to the correct sort order, and turns
the info message about incorrect ordering into a warning. After this
lands parameters.yaml changes will always require that the items stay
in the sorted order enforced by the extension.
Part of bp:api-ref-in-rst
Change-Id: Ib890d369a8b50a8cd920f7b19ef13f44b3e657df
This makes the keypair object load first from the API database,
falling back to the main database as necessary. Creates happen in the
API database only now.
Since the Instance object uses this object to patch up its keypairs
field on the fly, this adds a localonly parameter to the get method so
that we don't end up with compute nodes calling back up to the API
database in the lazy-load case. Only Instances that were created before
the previous patch will be missing keypair data, and so we're
guaranteed to have their keypairs in the main database (if at all).
Related to blueprint cells-keypairs-api-db
Change-Id: I700cf8633f694c933f17dd133fa6c84c2beac4c0
fake_imagebackend had a Raw class which was used by only a small
number of tests. This change refactors the tests to avoid the
requirement for this class by using mock.
Change-Id: Iffdc0c66f1ec4428b98fffc807af636dd491a080
Functions were passing in user_id and project_id to these functions,
but they were not being used. This change allows a subsequent patch to
drop an instance object as a function argument which has no purpose
other than to provide these unused values.
Change-Id: I844b97523b28b327e76e01ef7f16b57a415418ec
Sylvain Bauza