In some situations, we may enter into a race-safe wait context for an
external event and then determine within the context that the event
would have already fired or for some other reason waiting is not required.
In that case, this introduces a VirtAPI method to abort the wait for
specific events in a clean way.
This should be used sparingly and only in certain circumstances where
it is clear that the event has already occurred. For example, if the
action triggering the event was initiated outside of the wait context,
we can enter the wait context (establishing a waiting event to capture),
and then poll once for completion of that thing. If incomplete, we will
block and wait on context exit as usual. If the thing we are waiting for
has already completed, then we can avoid the long wait by calling the
early-exit helper and avoid what would ultimately be a timeout and
failure.
We are specifically adding this to address the cyborg scenario as follows:
Once we select a host in the conductor for an instance build, we can call
to cyborg to start the preparation (i.e. programming) of the device on the
destination host. This takes time, and by kicking it off early, we can
overlap that process with other work we have to do. Because that will send
an event upon completion, which will be routed to the compute, we will race
to start the build process on the compute and begin the race-safe event
wait in the compute manager. Instead of collapsing the window and waiting
synchronously, we can trigger it early, then start the wait in the compute
later, check for early completion *after* the wait has been set up, and then
exit the wait early if we determine that the event had already been sent.
This allows us to be async with cyborg across two services while still being
safe in the critical region where we need to setup the wait before we rely
on the event being sent.
Change-Id: I8e5a0683069b2f322cb059d6eb501d732d1bd851
This adds the VirtAPI interface to add/remove the
COMPUTE_STATUS_DISABLED trait on a compute node
resource provider based on whether or not the related
compute service is disabled. This will be used in future
patches by both the ComputeManager's set_host_enabled method,
which will be called from the API when a compute service is
enabled/disabled, and from the libvirt driver when the
hypervisor connection is dropped/re-connected.
Note that some refactoring was required to make sure the
ComputeManager, ResourceTracker and ComputeVirtAPI are all
using the same SchedulerReportClient instance with the same
ProviderTree cache since the set_traits_for_provider method
relies on the cache to determine if updates are flushed back
to Placement.
Part of blueprint pre-filter-disabled-computes
Change-Id: Ie756ba5e405ad988667c75a723f1c9b9ff3e4a93
Provider firewall rules functionality is not in use and hasn't been
for a very long time. The api for this was removed in [1] and db api
methods for adding/removing rows in the associated db table have not
been used since.
Stop refreshing those rules as it is essentially a no-op and indeed a
costly one that includes a rpc round trip to the conductor to get
back an always empty db result. This should have a positive impact on
instance boot performance since the conductor call happens to live
inside an externally syncronized block of code.
Removes related compute rpcapi/manager code that were missed in a
recent cleanup[2]. Since this functionality hasn't been in use since
Havana timeframe(!), it should be fairly safe to remove without first
deprecating it.
Also removes the now unused virtapi method provider_fw_rule_get_all()
and the virtapi itself from virt firewall driver initialization.
[1] Commit: 62d5fae8d1
[2] Commit: e6f7d80417
Change-Id: Ifbb2514b9bc1445eaa07dcfe172c7405fd1a58f7
Partial-Bug: #1016633
This method was only used in the xenapi driver, which has since been
converted to use Objects. This removes the call from VirtAPI, the
conductor API, and deprecates it from conductor manager.
Related to blueprint compute-manager-objects-juno
Change-Id: I43b8c4bc201361ce79d56cac91a8944d18c03ab2
This removes the now-unused instance_update() method from the VirtAPI.
Related to blueprint virt-objects-juno
Change-Id: Iaa55e7156244c9cdf7558e23ecab49db162daa37
Since we use objects exclusively in compute now, we no longer need the
virtapi methods for getting the BDMs in the virt layer, as objects can
be used.
Part of blueprint: icehouse-objects
Change-Id: I34bafd8c0dbd412e9c11106793be97f3469867f3
This makes compute manager's virtapi expose a context manager
that lets virt drivers do something that doesn't complete until
an external event is triggered.
Related to blueprint admin-event-callback-api
Change-Id: I00b2821200f89a04f27963153805280c0063fd57
The flavor_get() in VirtAPI and instance_type_get() in conductor are
no longer needed by the virt drivers. This patch deprecates the
function in conductor's API and removes it everywhere else.
Related to blueprint compute-manager-objects
Change-Id: I782ee449df98a198f625b946c650ebff56711b8e
We don't need to have the vi modelines in each source file,
it can be set in a user's vimrc if required.
Also a check is added to hacking to detect if they are re-added.
Change-Id: I347307a5145b2760c69085b6ca850d6a9137ffc6
Closes-Bug: #1229324
This patch makes DriverBlockDevice use objects to do the database
updates. The object will be kept as a private object attribute and the
only change in the external API of the DriverBlockDevice objects is an
addition of the save() method.
This patch also removes the block_device_mapping_update method from the
VirtAPI class as that functionality can now be handled by
DriverBlockDeviceDict class (using BlockDeviceMapping objects
internally).
Also cleans up tests and simplifies some code in the libvirt driver that was
relying on virtapi to do the db updates.
Related to blueprint: icehouse-objects
Related to blueprint: clean-up-legacy-block-device-mapping
Change-Id: Ibafd1a05fb1050349ad12c0cafac77f64a8e96d8
Renames the virtapi.instance_type_get method to flavor_get. Updates the
directly related tests and subclass implementations of VirtAPI.
This patch does not propagate to all related code like conductor API,
that will be handled in a later patch for the blueprint.
Part of bp flavor-instance-type-dedup
Change-Id: Ic47da9aa578d449a4ce542d2d017840f1a8132a7
This patch removes the no-longer-needed security_group-related
methods from VirtAPI.
Related to blueprint compute-manager-objects
Related to blueprint virt-objects
Change-Id: I0326f25754e7a13dfc18f207242052412189c743
The aggregate_metadata_add() and aggregate_metadata_remove()
methods are no longer needed in virtapi and conductor. This
patch removes them from the former and deprecates them in the
latter. Also, aggregate_get_by_host() is no longer needed in
virtapi, so remove it from there.
Related to blueprint compute-manager-objects
Change-Id: Ia057dcc43c555187a4a1466a9e748b978c46d4a4
This patch makes the necessary changes in the libvirt driver to enable
it to use some of the features of the new block device mapping format.
After this patch it will be possible to set the bus, and device_type per
block device, and libvirt driver will honor these when spawning an
instance (note that attaching a volume still does not use the new data
format).
It utilizes some of the existing code in the blockinfo module to be able
to default device names (it does so by overriding the methods introduced
in I84541f8ff6e1b5978734e5def69946d014c66fdf), and also assign default
values to fields like device_type and disk_bus if it is not provided or
if it is bogus. As this implies the driver changing the block devices in
the database, a new virtapi method block_device_mapping_update is added
to accommodate this. Some of the libvirt specific code paths in the
general defaulting function in compute utils have been removed as they
are not needed since the driver now takes care of this.
Further to that, this patch modifies some of the code paths in the
libvirt driver that use the block device info directly (and not through
the blockinfo module) to be aware of the new format. Due to very nicely
factored code - there were only a few instances of this in the driver
itself.
It also overrides the libvirt driver's need_legacy_block_device_info
method to tell the compute manager to feed it the new format when
needed.
This patch concludes the blueprint: improve-block-device-handling
Change-Id: I8efd6af6706a097fb540e040a86ccbeaf131631f
Add another conductor api method to the virtapi. This is needed by the
following patch: https://review.openstack.org/#/c/42812
Part of blueprint qemu-assisted-snapshots
Change-Id: I21d0ebe9f83423d504f7626f0d048b31945156d9
The instance_get_all_by_host() and instance_get_by_uuid() methods are
no longer needed by any virt drivers, so remove them from the virtapi..
Related to blueprint unified-object-model
Change-Id: Ib51bf3b3e068d69e7a75f7312f03db6c85e7cf49
...and remove the use of instance['extra_specs'] from the libvirt and
baremetal virt drivers. Also remove the hack in instance_update()
which places them there in the first place.
Fixes bug 1133572
Change-Id: I39e9fabb28b48dc52ec47f58d76b0bf2c6ee0204
This patch adds the following methods to conductor's API and
redirects the use of them in nova-compute to conductor:
security_group_get_by_instance()
security_group_rule_get_by_security_group()
This involved changing the corresponding VirtAPI methods to
accept actual objects instead of IDs, to avoid introducing
additional DB messaging behavior.
Related to blueprint no-db-compute-manager
Change-Id: I14c2bcd181d0e0a1ec17130917c1a7eb0a091cf2
This patch moves the following aggregate operations from compute
to conductor:
aggregate_get_by_host()
aggregate_metadata_add()
aggregate_metadata_delete()
In order to do that, it also changes the signature of the corresponding
VirtAPI methods to take the aggregate object instead of just the id,
so that we don't re-introduce any db messaging behavior.
I debated about using the set_delete mechanism in the metadata_add
API to avoid adding a separate conductor API for delete, but decided
that it wasn't worth the extra round trips, no matter how much I may
wish it were.
Change-Id: Ic0117879c8ce576cdc8e6c5af018bb918a15d4c0
This patch makes nova/virt use the metadata attached to the
aggregate object instead of querying it separately. This allows
us to remove a method from VirtAPI and avoid adding another one to
conductor to support it.
Change-Id: I4b9ff59147d30ff6f71fa66e838f060b8853dc95
This makes hacking.py complain if someone adds something like:
from nova import db
into any of the files in nova/virt/* (aside from the fake.py file).
It also removes the rest of the dangling db imports that are no
longer needed.
Yay!
Change-Id: Iba3d53b87e65e33a55f8e5033b5d1d33b28d12f7
This adds a method to the VirtAPI for fetching information about
the guest agents. It would be nice to avoid having to have this be
passed into the virt driver on spawn (and migrate, and resize),
but I think that asking the compute manager to guess what the virt
driver wants for each of the parameters (or grab them all) is
probably no better.
Related to bp:no-db-virt
Change-Id: I27fb4bd85e6c6bb11e01fb652b199956df88804d
This patch moves the following network security-related
methods to VirtAPI:
security_group_get_by_instance()
security_group_rule_get_by_security_group()
provider_fw_rule_get_all()
In order to make this change, the _provider_rules() method
of the FirewallDriver was changed from being a staticmethod
to a regular instance method. All uses of it were in the
context of an actual instance, so I saw no reason to keep
it static, which would have complicated the use of the VirtAPI
methods.
Related to bp:no-db-compute
Change-Id: I260c96b6aa4bbab694b74087f704b6405360b0bf
This patch moves the following virt driver host aggregate
operations to the VirtAPI:
aggregate_get_by_host()
aggregate_metadata_get()
aggregate_metadata_add()
aggregate_metadata_delete()
In the process, a bug was found in the xenapi/host.py code
that raises an AggregateHostNotFound error in such a way that
a KeyError is generated. This changes that behavior to raise
a NotFound instead, since the former expects you to already
know the aggregate_id, which we do not. This patch extends the
XenAPI host_maintenance_mode test to exercise this error path,
as well as the one where a host is not found within the returned
aggregate.
Related to bp/no-db-compute
Change-Id: I006665bfb27774d2eeb713b79c188ca53f6fb00b
This adds two methods to the VirtAPI for instance_get_*
operations, removing direct calls of those from the
drivers.
Change-Id: I0be42f73fb71a61bf6c46708d5879f7f8ade294d
This patch introduces a VirtAPI class which will house
callbacks provided by the manager to the virt drivers, allowing
things such as direct database accesses to be pulled out of
the virt drivers and delegated to another service.
As a first step, this introduces an instance_update() method
and makes all the virt drivers use it instead of direct calls
to db.instance_update.*().
Change-Id: I2e40831f5cfb20a03b304097d84d592aab035ef1