Dan Smith [Tue, 29 Nov 2016 15:05:17 +0000 (07:05 -0800)]
Never pass boolean deleted to instance_create()
This explicitly converts the deleted flag to an integer (which will
always be zero) at Instance.create() time. We already require it to
be False, but if set, we will pass the boolean instead of an integer,
which will confuse some (self-respecting) DBMs.
Matt Riedemann [Mon, 28 Nov 2016 21:45:58 +0000 (16:45 -0500)]
Fix expected_attrs kwarg in server_external_events
The Instance.get_by_uuid method takes an expected_attrs
kwarg which needs to be a list or tuple, not just any old
iterable like a string. Because of how the underlying
Instance object code massages this value, it's not a hard
failure but does mean you don't join the columns you expect
when getting the instance.
This makes it a list and makes sure the stub in the unit
tests is checking for valid values.
Dan Smith [Mon, 28 Nov 2016 15:24:21 +0000 (07:24 -0800)]
Check deleted flag in Instance.create()
An attempt to create an instance with the deleted flag set will
not work as intended, especially from instance.create(), which
can't properly pass the yet-to-be-determined deleted=id protocol.
This makes Instance.create() throw an error like the one for
being already created, and fixes the one test where we depend
on this working.
Sylvain Bauza [Mon, 28 Nov 2016 17:36:53 +0000 (18:36 +0100)]
Default deleted if the instance from BuildRequest is not having it
We should already have the rehydrated instance having the deleted field being
set. That field is also a BooleanField type, so we should never try to cast it
from an integer (even if we support it). Instead, we need to make sure that if
the field is not set for any reason (mostly because an Instance wasn't persisted
before we persisted the BuildRequest object that was nesting it), then we would
default the deleted field to False.
Markus Zoeller [Tue, 22 Nov 2016 16:08:14 +0000 (17:08 +0100)]
libvirt: Acquire TCP ports for console during live migration
During a live migration process we reserve serial ports on
destination host and update domain XML during migration to
use the new reserved ports from destination.
If the migration succeeds we release ports on the source host.
If the migration fails we release reserved ports on the
destination host.
Roman Podoliaka [Thu, 3 Nov 2016 10:51:48 +0000 (12:51 +0200)]
vif: allow for creation of multiqueue taps in vrouter
This extends the work done in libvirt-virtio-net-multiqueue bp to
allow for enabling multiqueue mode for vrouter VIFs (OpenContrail).
In case of vrouter mechanism is slightly different and a tap device
created by nova-compute must already be in the multiqueue mode,
when it's passed to vrouter.
Implements blueprint vif-vrouter-multiqueue
Co-Authored-By: Michal Dubiel <md@semihalf.com>
Change-Id: I7b20650c8a772fdaa05707e0dfe27ad32481a2d3
Balazs Gibizer [Thu, 10 Nov 2016 14:52:32 +0000 (15:52 +0100)]
Fix notification doc generator
The doc generator only picked up the event types related to instance
actions because the doc generator looked up the registered notification
classes only. Until now, only the instance related notifications were
imported in the doc generation environment so the other notification
classes were not registered.
This commit explicitly imports the modules that defines the notification
classes to make the doc complete.
Hieu LE [Mon, 16 May 2016 04:40:10 +0000 (11:40 +0700)]
Config options: improve libvirt help text (2)
This commit adds additional help text to the following
subset of options: live_migration* and snapshot_image_format.
This commit also formats the help text of some of the other config
options and removes parts of the help texts of other config options
we agreed on to clean up.
In virtuozzo 7 we have changed disk bus from sata to scsi.
Sata is not supported in virtuozzo 7.
We don't need to support sata bus for virtuozzo in nova.
Virtuozzo 6 may work with python 2.6 only and
it's not possible to run upstream nova on virtuozzo 6.
We always use this patch in our internal infrastructure
to run openstack on virtuozzo 7.
Also in this patch we have changed tests for hypervisor version.
We don't need to check libvirt version in case of Virtuozzo hypervisor.
Because Virtuozzo 7 always has libvirt with
support of 'parallels' virt type.
Host.get_connection() does 2 types of job when initialising a new
connection:
1. Register event handling callbacks on the connection itself.
2. Call the _set_host_enabled in the driver to enable/disable the
compute service.
The first is essential to run before the connection is used for
anything. The second needs only to run eventually once the connection
is established.
This patch creates a new helper thread which runs connection up/down
callbacks asynchronously to the caller. This means that the caller of
get_connection() returns as soon as the connection is usable, and the
driver callback happens concurrently. This is a minor improvement
currently, but will be more useful when we add additional work to the
connection up/down event. It also means that the callback runs without
holding _wrapped_conn_lock, which it doesn't need. This means the
callback itself can call get_connection() without deadlocking, and use
the connection which was just initialised.
In updating the callback logic, we also fix a minor bug: previously we
would not generate down/up events if we detected a failed connection
and succeeded creating a new one on the first attempt. This is
currently only of limited importance, as we are only marking the
service down or up for the scheduler, but could be more significant
when we add additional work to the callback.
This patch is preparation step to move the instance creation to
the conductor. The goal is to move out the instance.create call from
the _provision_instances method.
The _provision_instances method return value is changed
from list of instances to the tuple containing a list of build_requests
and RequestSpec object. We also return the instance_mapping list so
that we can properly clean up residue if we fail to create in the caller.
Co-Authored-By: Dan Smith <dansmith@redhat.com>
Implements: bp cells-scheduling-interaction
Change-Id: I60abcd4f27dc877c4e420071be77c9fdb697ad99
Matt Riedemann [Wed, 23 Nov 2016 01:44:53 +0000 (20:44 -0500)]
Add TODO for returning a 202 from the volume attach API
Attaching a volume is an RPC cast from the API node to the
compute node, so we should return a 202 instead of a 200
in the response. Making that change would break Tempest though
which expects a 200 response code, and we have several other
APIs with similar response code issues:
http://paste.openstack.org/show/590154/
So this just adds a TODO for the same bucket of issues which
we'll probably need to handle in a single microversion.
Dan Smith [Thu, 3 Nov 2016 17:50:26 +0000 (10:50 -0700)]
Refactor two nearly useless secgroup tests
There are two tests that masquerade as "compute api tests" to
validate some instance security group associations. However, those
are just there because it's a convenient place to create instances
with a full complement of things. They depend on behaviors we're
about to move, and are also slated to be irrelevant when we remove
nova-network. In the meantime, move them closer to the other tests
for the bits they are exercising to get them out of the way of
the following patch.
projects / osstest / openstack-nova.git / log