Since the following change:
If1ab969c2002c649a3d51635ca2765c262e2d37f
Neutron supports this vnic type, which ties in with the work that
enabled PF passthrough.
This patch makes sure to properly translate the 'direct-physical'
vnic-type port from Neutron to a request for a PF.
Change-Id: I51af36fc2edca3404a8f9efb32462f3680944be1
Partially-Implements: sriov-pf-passthrough-neutron-port
It has been reported that the exception LiveMigrationWithOldNovaNotSafe
is not useful since the change
I5651fb7ba95f38e2e2f8a48a98ff04072c6bb885.
This patch will cleanup the definition and the occurences of
that exception.
Change-Id: I7a5b677904d83104c4f5367b0245eebd422e2338
Closes-Bug: #1550282
The new vnic type is defined by Neutron in the following change:
If1ab969c2002c649a3d51635ca2765c262e2d37f
We define it for Nova with this patch, and add a vif driver for plugging PFs -
it's really just a simple hostdev passthrough, which is already used so
we just abstract the code a bit.
The patch that same vif type to Neutron (it got overlooked by the
original work) is here:
https://review.openstack.org/262604
Change-Id: I1dc5601027ac97158d409d799b314a0c49968ce5
Related-blueprint: sriov-pf-passthrough-neutron-port
'live_migration_flags' and 'block_migration_flags' are used for
bitwise arithmetic -- they should not default to 'None', but to '0'
instead.
Change-Id: I48e65b0dd977a3dbfdbdaa326d4fb654b4f0da12
We need to start populating the mappings of instance to cells. For now a
mapping with a null cell_mapping will indicate that the instance has not
yet been scheduled and that list/show requests should be honored using
the persisted RequestSpec/BuildRequest. That work will be a followup to
this one.
There's no need to leave instance_mappings loitering in the database if
there are no cells yet. So if a scheduled host does not belong to a cell
the instance_mapping will be removed. The instance will be mapped later
as part of the migration process to cellsv2.
Partially-implements: bp add-buildrequest-obj
Change-Id: I6f02e966d2cef85f98b4b64aedd8c352387af15d
The VIF tests currently directly call the VIF type
specific plug_xxx and unplug_xxx methods. Switch the
tests to call the generic plug / unplug methods so
that the tests exercise the dispatch code too.
Change-Id: I0f6c74fece5fe71a704bfc9ac66d810dbf9068ca
xenserver config options under 'xenserver' section of nova.conf are
centralized to "nova/conf/xenserver.py"
bp centralize-config-options-newton
Change-Id: I5e7b2fb0ff77ac16047189436e60b0faffbc7f97
This patch fixes an issue which was introduced by this
change If3edc1965c01a077eb61984a442e0d778d870d75.
Usually the vif config is of type LibvirtConfigGuestInterface,
but some vif use LibvirtConfigGuestHostdevPCI config
(e.g. the ib_hostdev). The difference is that
LibvirtConfigGuestInterface keeps the pci address in source_dev
while LibvirtConfigGuestHostdevPCI has domain, bus, slot and
function, instead of relying on the vif config type we can take the
pci address for the neutron port.
Closes-Bug: #1560860
Change-Id: I62a7ff16f1c9c5da923451520fbeeabb5cc0c5c6
Make a single db call to get bdms for all instances instead of one
call per instance.
Change-Id: I74864b398f2d17a24b9ed676945183401e9872a0
Closes-Bug: #1484847
Tempest change 9bee3b92f1559cb604c8bd74dcca57805a85a97a
renamed a test in our blacklist so update the filter to
handle the old and new name.
The Tempest team is hesitant to revert the change so we
should handle it ourselves and eventually move to using
test uuids for our blacklist, but there might need to
be work in devstack-gate for that first.
Change-Id: Ibab3958044c21568d7fbbe0a298bb40bbbc20df3
Closes-Bug: #1562323
The config options in ldapdns.py got moved
to the new central location "nova/conf/network.py"
Implements: blueprint centralize-config-options-newton
Change-Id: I9436c523d0ad7be8ae5cd177d1ce16a7d73f1eca
This just copies over the check from the nova database which ensures
that any added migrations have a functional test, unless explicitly
added to a skiplist.
Change-Id: Ib1c483c6e52667d3d7616d5b273efb7b73333b76
This makes these tests use object mocks and methods instead of low-level DB
routines.
This also cleans up several unused stubs from test_flavors_extra_specs
which are useless because the tests are actually exercising the API
validation code, so they never get to the Flavor object or database.
Co-Authored-By: Matt Riedemann <mriedem@us.ibm.com>
Change-Id: I54150cf7cff37ca827dfd8a0290bfe97ed8b8df6
This patch adds a config option to the [ironic] group, allowing the
operator to specify a cacert file with which to connect to the
ironic-api service.
This corresponds with the way encrypted connections to other OpenStack
services are configured.
Change-Id: Ice1d6c3f6fc911c4f35fe0283e3d1e9dd8b0e1a7
Closes-bug: #1561796
We're not using Hungarian notation so there's no need to add an
'_opt' suffix on opts. Remove this.
Change-Id: I354d1398f1da30c0d9bb9739cfab74fe397bb042
Now that the WSGI opts have been added to a group, there's no longer
any reason to keep the 'wsgi_' prefix for some of these opts around.
Remove it, ensuring the old names are stored as deprecated names.
Change-Id: If39bed3ed2335b6f96455870f1a47cb868d21f39
Since now we provide the original RequestSpec for move operations (unshelve,
live-migrate and evacuate), it can also provide the original force_hosts/nodes
to the scheduler.
In that case, it means that if an admin was asking to boot an instance forcing
to an host, a later move operation could then give again the forced value and
then wouldn't permit to get a different destination which is an issue.
TBH, that is not a problem for live-migrate and evacuate that do provide an
optional host value (which bypasses then the scheduler) but since unshelve
is not having this optional value, it would mean that we could only unshelve
an forced instance to the same host.
Change-Id: I03c22ff757d0ee1da9d69fa48cc4bdd036e6b13f
Closes-Bug: #1561357
Right now InstanceMapping exposes the cell_mappings.id db field which is
just an implementation detail of the db relationship and should not be
exposed in the object. It is also useless as a way to look up the actual
CellMapping through that object interface. And InstanceMapping is only
looked up in order to find a CellMapping.
So the CellMapping should be joined during the db query and loaded on
the InstanceMapping object by default.
Change-Id: Ia8691b76bba310327bfe0995964525409794d1af
We already had loading extra_specs working from the API DB, thanks
to the SQLA relationship. This makes saving them work against it
as well.
This adds a test_save_api() copy of the test_save method with the
appropriate changes, which also increases coverage over the access
changes from a previous patch now that we can run the whole save()
method against API. Later we'll just delete the old test method
when we drop compatibility for saving to the old database.
Further coverage for this will be increased in a later patch,
when we gain the ability to create flavors in the API DB natively,
which will let us try to run more functional tests against flavors
in both databases the way we'd expect in production.
Related to blueprint flavor-cell-api
Change-Id: I63706bde5eaaa9af3b864307b446ed0cf30d8a1b
This makes the access-related bits of the Flavor object work when the
flavor is in the API database instead of the main one. Included are
fixes for lazy-loading projects, add/remove access, and the projects
part of save(). In order to try to improve performance, this creates a
property on the object called "in_api" which will detect whether the
flavor is in the API database, caching the true case only so we can
stop checking. This is not a remotable field, which means it won't go
over RPC (and thus doesn't need a version bump), but since we only ever
do the access manipulation from the API, this is fine and we still get
the benefit.
Related to blueprint flavor-cell-api
Change-Id: I03a856235d653cf8831740a344072a897719bfa6
Nikola Dipanov