This enables an admin to create a cell mapping and corresponding
host mappings in the API database. For example:
nova-manage --config-file nova-cell.conf cell_v2 map_cell_and_hosts
With the following options:
--transport-url (required) - The transport url for the cell MQ
--name (optional) - The name of the cell
--verbose (optional) - Output the uuid of the created cell
There is no release note since the command is only to be used
experimentally and for testing at this time.
Co-Authored-By: Sylvain Bauza <sbauza@redhat.com>
Change-Id: I7a29782e7cbafddd90a627992cac1f7f47045a36
The sample policy file was updated recently and this releasenote
explains the changes for operators.
A more narrowly scoped releasenote for a previous change along similar
lines has been removed since it is covered under this note.
Change-Id: I11bde778e9fe1f3a70d9fac213b40f05f07e7e47
The bullets shows up as separate features when looking
at all release notes together, which is confusing. We
should document these as sub-bullets under a common
block of text for the overall feature.
Change-Id: Id37ea28590a1218e574b415c404dc29fbd577aee
Right now, we only create the ec2_ids for an Instance when they are first
accessed, not at instance creation time. However, we always touch them
later for building metadata, configdrive, etc, which means we end up with
an expensive lazy-load later.
This makes us always create ec2_ids at instance create time. Since it's in
instance.create(), it runs on conductor, straight to the database, avoiding
a round-trip later (assuming this instance is passed to the compute node
for create and/or that the field is specified in a later call under
expected_attrs).
Partial-Bug: #1540526
Change-Id: I29bc317f990bfa0f01b4f9615699debcc3a3c2c6
This reverts commit 70604db8da.
The commit adds a config option that is required on both the scheduler
and the compute hosts which is not the direction we want to be going
in, and want to make sure that compute hosts are exclusively
responsible for the data that the scheduler service uses.
Change-Id: I2465e1bee618a552132d659014ea96cdbda161d6
When reviewing an unrelated patch I saw this line of code which is
definitely wrong. This looks like a copy / paste error from
Ie74939e543155bc42705b28e1b44d943ef54ebdc.
Change-Id: Ia3aca2df622713dee5cde091c4d48baa803c678f
Closes-Bug: #1555602
No config generator hooks should ever be registered with a name that
belongs to another project. In this case, using oslo.middleware.cors
means that *every other project* that loads the middleware gets this
application's defaults when the generator is run on a system with
everything installed (such as a dev box with devstack). Use the name
of the app instead, to ensure that the defaults are only set when this
app's sample config and documentation are being generated.
Change-Id: I6a8c7d44b9db9325003ff2fdb667b0ced7739e96
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
During the nova.compute.Claim.__init__() call, there are a bunch of
_test_XXX() methods that are called. These methods should test to see
whether the requested resources of various types can be satisfied by the
inventory on the ComputeNode. However, that inventory *should not* be
claimed for a particular request during the Claim object's constructor.
The Claim._test_pci() method was *actually* claiming the PCI device for
the requested instance. Unfortunately, this meant that if an instance
launch request's demand for a resource like RAM was not able to be
satisfied by the compute node but the launch request's demand for PCI
devices *was* able to be satisfied by the compute node, those PCI
devices were actually claimed for the instance even though the claim
itself would end up being aborted. This resulted in a data
corruption/inconsistency where a PCI device would be claimed for an
instance that actually was not running on the node.
This patch moves the claim of PCI devices out of the _test_pci() method
and into the ResourceTracker.instance_claim() method. In the process of
fixing this bug, it was discovered that the unit tests for the Claim
object with regards to PCI devices were just plain broken. They were
testing for nothing at all because of the way the Claim constructor
works. These unit tests were reworked completely, along with the
MoveClaim unit tests which similarly were not testing the PCI code paths
at all. An additional unit test was added on the resource tracker to
verify that nova.pci.manager.PciDevTracker.claim_instance() is called
when PCI requests are included and satisfied by the Claim.
Change-Id: Icf75439a552de84ec31c1a47faeee3caf8a5b0a7
Closes-bug: #1549984
SecurityGroupAPI.get_instance_security_groups() takes instance.uuid as
parameter and use that to fetch instance security groups from the db.
Since all callers of this method has the instance to begin with we can
use it to get security groups without the extra db call.
Change-Id: I87769999839871c1a8d29c9013789d2611b8bccf
Closes-Bug: #1521675
Since nova can calculate block_migration we might end up with
a case where block_migration is None while migrate_data.block_migration
is True.
Both drivers that support block live migration, Libvirt and Xenapi,
use migrate_data.block_migration already, so we should switch to use
it everywhere, instead of in drivers only.
Change-Id: Iaa8aea3cb58ed0864a6a38d4a163649f52e32c5c
Closes-Bug: #1552303
The objectification of the live migration data ended up with a bug in
the compatibility path for the pre_live_migration result where we
convert a legacy dict response back to an object. The legacy dict
processing looks for 'pre_live_migration_result' in the input to
trigger handling of those keys, but we weren't properly wrapping the
result like that so it was never digesting those keys.
Change-Id: I5142e1cb9d526c92529fc24ee0441b5730931160
Closes-Bug: #1556126
Instances left in a deleted state at compute manager startup were
not being explicitly cleaned up in the resoruce tracker. To address
this _update_resource_tracker is now called from solely the
_complete_deletion method. That method is called both by the
_init_instance and _delete_instance code paths, both of which should
be doing cleanup in the resource tracker when the vm is DELETED.
Note that this change does mean that if _delete_instance has an
exception, _update_resource_tracker will not be called. This is
considered okay because we cannot guarantee at which stage the
exception happened and the state of the resources involved. For safety
it is better to err on the side of "in use".
Change-Id: I586c0305ea0e20d98697bc9173ca0f89dc2b228c
Related-Bug: #1227925
The _live_migration_operation method is accessing the nullable
attributes 'serial_listen_addr' and 'target_connect_addr' on the
LibvirtLiveMigrateData object which might not be set on the object.
Since they aren't lazy-loadable, this results in a NotImplementedError
if the attribute aren't set. This is fixed by adding conditional checks
in _live_migration_operation for the nullable attributes. Note that
bdms is nullable=False in the LiveMigrateDataObject and should be set
when the migrate_data object comes to the virt driver, so the test case
is updated in this case to fix the bdms attribute access.
There was a test hitting this, but because the libvirt driver runs
_live_migration_operation in a thread, the error was just being
logged and the test would pass.
So to fix that, the SpawnIsSynchronous fixture is used in the test
class to make the _live_migration_operation synchronous for that
test.
However, that doesn't fully resolve the gap in the test because
of the @catch_notimplemented decorator used on the test case. That
is meant for virt drivers which don't implement the live_migration
method but it can also allow silent failures in object attribute
access from bubbling up as failures. So this change also removes
that decorator from the test case.
Note that the tests themselves are pretty hacky in this case anyway
since while they are meant to be generic per virt driver, the
object passed down is LibvirtLiveMigrateData, which won't be
correct for xenapi, for example.
Closes-Bug: #1551925
Change-Id: I2744e99617d4e4834bb8372fa62dbad7686b1301
In normal usage utils.spawn returns an eventlet.greenthread.GreenThread
object which has a few methods defined on it. Currently the wait() and
link() methods are used in Nova. However the SpawnIsSynchronous fixture
was returning the results of wait() directly which led to an interface
mismatch. Normally utils.spawn_n returns a greenlet object which does
not allow checking the return but in testing we have never blocked that
capability before. This could be enhanced later to be strict for spawn_n
if we choose, but it is handy to have raised exceptions pass through in
testing.
SpawnIsSynchronous now returns a GreenThread object lookalike which has
wait() and link() methods that work as expected. This allows for the
removal of the wait() method from network/model.py:NetworkInfo.
A few mocks which emulated the improper behavior were also updated.
Change-Id: I1ded81f93235e217822e385ddd983b24c6359a53
There isn't instance-action reported by new live migration force
complete API. This is async API, so there isn't a way for user
to know if there is error happened in this API. This patch add
instance-actions report to it
Change-Id: I29dc8ce0aa576ef55d2a4dfbaa6bd1f2bfd90371
Closes-Bug: #1553050
There are three security issues fixed in mitaka.
The first two were documented for liberty 12.0.1 but we
apparently forgot to doc them for mitaka.
Related-Bug: #1524274
Related-Bug: #1516765
Related-Bug: #1548450
Change-Id: I3eba75f1fc86c4c9abd258042dfafc6df1f2405c
Jenkins