Currently it is not possible to override an existing image block device
by supplying the device with the same name at boot (see also
Ib1ba130042aabbbe7bb8d60fc212c66e446c1d73). Even though we want to
discourage usage of device names as much as possible in the Nova API (as
not all hypervisors can honour them), EC2 API requires that this is possible.
While we want to make sure we document that supplying device names at
boot is only really desirable if you want to override some of the ones
contained in the image, introducing a different labeling system just so
that we don't use the device names seems like an overkill for a feature
that does not seem to be very used.
This patch adds a method that will do this deterministically when
compiling all the block device information for the request.
It is also worth noting that The EC2 API allows only subset of block
device attributes to be overridden in this way (see [1]). This limitation
did not exist previously in Nova, and there seems to be no reason why we
would need that complexity, so it would be up to the EC2 compatibility
code to deal with this.
[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html#Using_OverridingAMIBDM
Doc-Impact
Closes-bug: #1370250
Change-Id: I60ecdcae81ff5dec34f0fa0a39e0739759a6fa59
MKS is the native protocol for VMware consoles.
DocImpact: two config properties are added in group 'mks':
'mksproxy_base_url' - specifies that base URL for the MKS proxy
'enabled' - enables MKS console
Implements: blueprint vmware-webmks-console
Change-Id: Ia494ce050bd4dc58e5947e7f07cc3c815a257004
This adds some notifications to two parts of the evacuation path that are
currently missing them. When the request is made, we synchronously fire one
indicating that we're sending the request to the conductor task manager. Then,
when that actually schedules a host and asks that host to do the rebuild,
we fire another. When it lands on the compute host, we'll get some notifications
about the rebuild starting, along with any errors.
Related to blueprint robustify-evacuate
Change-Id: I0054809573f04f03a3e4deeb482d61f280576ad3
This makes the evacuate process leave a record in the database about the
evacuation, and from what host it was being performed. Now, the compute
manager will use that breadcrumb trail to decide whether it should delete
locally-running instances, instead of just the hostname mismatch.
Since this does a query by migration_type, I added a unit test to the
test_db_api module to prove this actually works.
DocImpact: Deprecates the workarounds/destroy_after_evacuate config option
Related to blueprint robustify-evacuation
Closes-Bug: #1471887
Change-Id: I972c224dfb954a9f06e221c9235ee6e4889c2619
Up until now we would really only care about the size of ephemeral and
swap BDM entries'volume_size' being set properly, while we would rely on
Cinder to be the canonical source of truth for the size information of
snapshots and volumes.
There is some overhead in querying Cinder every time this basic
information is needed, and we do have a volume_size field in all BDM
entries already, so let's keep it up to date.
Change-Id: I9ffbb6cf40c1012f774a382cf1dcceba64637e6d
Related-bug: #1370177
Currently - we would happily accept the request, but fail to create the
block device mapping record for such a volume. The result was that the
boot request for such an instance would be accepted, but would not
create a volume.
Also fix the _volume_size API method that was 0ing out blank volume's
size by mistake.
Change-Id: I1d243aed78da7c026e55ea145397b070d619a567
Closes-bug: #1461638
Removed an useless variable in create()
And fixed a typo: considertaion --> consideration
Change-Id: I8ebd27701ae61db73deddb28b7321abd53798dfd
Closes-bug:#1460528
The get_image_metadata method has some unhelpful semantics
where it takes the image metadata from the instance's
system metadata record, and then overwrites it with the
current metadata associated with the original image.
The result is that, if the image metadata in glance was
changed after the instance was first booted, Nova will
end up making decisions based on image metadata that does
not correspond to that which the instance was booted with.
Since the image metadata controls many aspects of hardware
configuration, this could lead to incorrect behaviour when
modifying hardware later, eg disk/vif/pci hotplug.
What is worse, is that some of the nova operations will
update the instance system metadata when completed, thus
permanently overwriting the original image metadata with
the new data.
Almost all code which operates against an existing instance
is updated to use nova.utils.get_image_from_system_metadata.
The exception is the rescue codepath, which must use the
metadata associated with the new rescue image.
The nova.compute.utils.get_image_metadata method can thus
be removed from use, avoiding the problematic logic.
Closes-bug: #1460079
Change-Id: I35c9d26e3967e93a2c368c3f9fdc807a69816dd2
The CONF.non_inheritable_image_properties parameter lists a set of
image metadata properties that should be discarded when uploading
an image to glance during the snapshotting process.
This property is currently applied in the nova.utils method
get_image_from_system_metadata(), which causes the properties in
question to be discarded in a wide variety of non-snapshotting
related operations.
This is a regression caused by two commits:
commit 8e575be75c
Author: Xavier Queralt <xqueralt@redhat.com>
Date: Mon Aug 26 22:53:03 2013 +0200
Add methods to get image metadata from instance
commit 4389f2292a
Author: Xavier Queralt <xqueralt@redhat.com>
Date: Mon Aug 26 22:55:46 2013 +0200
Avoid errors on some actions when image not usable
Which moved handling of CONF.non_inheritable_image_properties out
of the compute API _create_image() method, and into nova.utils.
Fix this by moving the handing back into the compute API in its
original location.
Closes-bug: #1459760
Change-Id: Id630fe68678c4aa469ddbfdb3c757b264519e918
This patch fixes a case in compute/api that "knows" the magic name for
where we store actual object contents.
I'm not sure about this actual use and why we need it, but in order to
not block subsequent patches, this makes it at least use the proper
API in order to generate the magic attribute name.
Related to blueprint use-oslo-objects
Change-Id: I4fa95f03106130c64b672c32247686d109c760f7
This refactoring needs for futher review(-s).
First is here - https://review.openstack.org/#/c/170243
But it will be divided to separate reviews and some refactoring
should be done first.
Change-Id: Iac713b832b4cbc62ae69bfa1c4680c6932a735c3
After preparing the block device mapping for creating new instance(s),
check if any ephemeral and/or a swap disks have been already defined. If
that is not the case and the instance type requires them, create the
needed ephemeral and/or swap BDMs.
Closes-Bug: #1297325
Related-Bug: #1457527
Change-Id: I44b30625cf1023d20ebec5e38f46b7b8dab325f6
This patch was generated by the sixer tool version 0.2 using the
"iteritems" operation:
https://pypi.python.org/pypi/sixer
Manual changes:
- Don't change get_instance_metadata() in nova/compute/api.py:
fixed by the change Ifd455e70002eb9636b87f83788384127ba6edeeb.
- Don't change sqlalchemy code and
nova/tests/unit/db/test_db_api.py. sqlalchemy objects cannot be
converted to a dictionary using dict(obj) directly yet. It will be
possible with the change I702be362a58155a28482e733e60539d36c039509.
- Revert change in a comment in nova/objects/instance.py; the sixer tool
is limited and don't understand comments
- Reformat nova/virt/vmwareapi/driver.py to respect the 80 columns
contraint
Blueprint nova-python3
Change-Id: I81465661cb8a74778d70ba9b6641073f1effa49b
The function xrange() was renamed to range() in Python 3.
Use "from six.moves import range" to get xrange() on Python 2 and range() on
Python 3 as the name "range", and replace "xrange()" with "range()".
The import is omitted for small ranges (1024 items or less).
This patch was generated by the following tool (revision 0c1d096b3903)
with the "xrange" operation:
https://bitbucket.org/haypo/misc/src/tip/python/sixer.py
Manual change:
* Replace range(n) with list(range(n)) in a loop of
nova/virt/libvirt/driver.py which uses list.pop()
Blueprint nova-python3
Change-Id: Iceda35cace04cc8ddc6adbd59df4613b22b39793
This reverts commit d1baa9fe7e
The change introduced a race on delete where there isn't a host while
prepping block devices and we hit a NoneType error in nova-compute.
There was also a recheck grind on the original change showing it wasn't
safe and needs to be reworked.
Change-Id: Id4e405e7579530ed1c1f22ccc972d45b6d185f41
Closes-Bug: #1456771
Related-Bug: #1448316
Commit 01be083 misses unlock_override policy check in V2.1 REST API layer.
This patch fixes this bug and adds related unittest.
Partially implements bp nova-api-policy-final-part
Closes-Bug: 1429126
Change-Id: Ie5481267d0631fae7f413e63ae6c38656d3ca933
API.get_instance_metadata() of nova.compute.api creates an useless copy
of a dictionary: return directly the original dictionary created by
SQLAlchemy.
Change-Id: Ifd455e70002eb9636b87f83788384127ba6edeeb
This change does some additional cleanup like removing the now orphaned
_spawn() method and a related test. Furthermore it does away with some
rpcapi test stuff that no longer applies and also makes sure we send
objects instead of primitives in all rpcapi tests. Finally, some left-
over parameters in the client-side attach_volume() method are removed
since those are no longer needed.
Change-Id: I74e270304e03a843e6051afcaae7812af5564875
Replaces db.instance_get_all_by_host()
with objects.InstanceList.get_by_host()
also, fixed several unit test cases fail by using
mock to replace stub.
Closes-Bug: #1390483
Change-Id: I7da701f37d162f97b924cb8eede76de4f1c8bf7a
If an instance is booted from a volume, shelved, and goes into an error
state due to some reason. Volume from which instance is booted, remains
in-use state even the instance is deleted because instance has no host
associated with it.
Called _local_delete() to detach volume and destroy bdm if instance is
in shelved_offloaded state or has no host associated with it. This will
cleanup both volumes and the networks.
Currently in test_servers.py, "test_delete_server_instance" executes
similar to "test_delete_server_instance_while_building". This is because
"test_delete_server_instance" calls instance.save() method which updates
vm_state to building where it should be in active state.
Fixed "test_delete_server_instance" to test deleting an instance which
is in active state and has a valid host.
Closes-Bug: #1404867
Closes-Bug: #1408527
Change-Id: Ic630ae7d026a9697afec46ac9ea40aea0f5b5ffb
Currently, the Subject created for the X509 certificate
is too long, resulting in exceptions and failing to
create the keypair.
This change shortens the Subject.
Unit test added to prove the issue's existence.
Issue found by: Andrey Kurilin
Co-authored-by: Andrey Kurilin <akurilin@mirantis.com>
Change-Id: I7885c120ce81a22d416f806779bf9a12092d5040
Closes-Bug: #1447653
The recent compute rpc api version bump missed out on the security group
related calls that are part of the api.
One possible reason is that both compute and security group client side
rpc api:s share a single target, which is of little value and only cause
mistakes like this.
This change eliminates future problems like this by combining them into
one to get a 1:1 relationship between client and server api:s.
Change-Id: I9207592a87fab862c04d210450cbac47af6a3fd7
Closes-Bug: #1448075
When running the "migrate" operation and the
CONF.allow_resize_to_same_host is set as "false",
the CONF.allow_migrate_to_same_host doesn't work
in the function 'resize' from nova/compute/api.py.
At the same time, there is no checking the
CONF.allow_migrate_to_same_host in the function
_prep_resize from nova/compute/manager.py
DocImpact: remove the CONF.allow_migrate_to_same_host
Change-Id: I4c54c7c6e0e5e37cc46c52350ba4ce2047325ef9
Closes-Bug: #1364851
In nova/compute/api.py _check_and_transform_bdm() method
There are 2 words spelled wrong in a comment about gibi.
outher -> other
unnecessasry -> unnecessary
Change-Id: I7e7f19c2d36af943c3ae3d7fbb1ef6469ebe13ec
Closes-Bug: 1443324
Related-bug: 1409142
As part of the fix for the related bug - we've added protocol checking
to mitigate MITM attacks, however we base protocol checking on a config
option that is normally only intended for compute hosts.
This is quite user hostile, as it is now important that all nodes
running compute and proxy services have this option in sync.
We can do better than that - we can persist the URL the client is
expected to use, and once we get it back on token validation, we can
make sure that the request is using the intended protocol, mitigating
the MITM injected script attacks.
This patch makes sure that the access_url is persisted with the token -
the follow-up patch makes consoles use that info.
Change-Id: I02a377f54de46536ca35413b615d3298967afc33
This removes the compute/api::update() method which used to support old-style
instance dict updates. The only users of this method were broken unit tests.
Related to blueprint kilo-objects
Change-Id: I53cb012665f9eaea628af2d25a4fc137dcd2313b
This patch will be backported to Juno and Icehouse so that
Nova can fail immediately to let user know that it's not
supported in that release.
Partial-Bug: #1313573
Change-Id: Ic84fa9e0b9c2d7b6cf49955aa4f0d44ade2b5397
Nikola Dipanov