openstack/nova - nova - OpenDev: Free Software Needs Free Tools

Only direct dependencies need to be listed in requirements.txt.
pyparsing was previously added to workaround installation ordering
issues, which is no longer necessary.
Change-Id: I45bdd1d0dabfcc7c80314c28072950cfc5a59615

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

This patch removes the check in the API that prevented having block
devices without 'device_name' and makes the compute manager capable of
guessing those names.
Before creating the instance, the manager will try to guess a valid name
using the method 'default_device_names_for_instance', which should be
implemented by the drivers, or defer to the generic function from the
utils module 'default_device_names_for_instance' which uses the already
existing 'get_device_name_for_instance' function.
It also takes care of assigning the correct device name to the root
device (boot_index=0) to make it agree with the field `root_device_name'
from the instance. If none were supplied - it will try to guess it by
calling driver 'default_root_device_name' or defer to the generic
'get_device_name_for_instance'. if driver does not provide it.
What is worth noting also is that, should the drivers override the
two methods mentioned above, the code should expect to be passed the
standard block device mapping format, and not the one used in other
driver methods.
DocImpact
Part of blueprint: improve-block-device-handling
Co-authored-by: Xavier Queralt <xqueralt@redhat.com>
Change-Id: I84541f8ff6e1b5978734e5def69946d014c66fdf

Add a temporary nova.notifier.Notifier helper class which translates
oslo.messaging.Notifier compatible calls into openstack.common.notifier
compatible calls.
This allows us to port the notifier code over to the oslo.messaging API
before actually switching over oslo.messaging fully.
This patch contains no functional changes at all, except that all
notifications go through this temporary helper class.
Some notes on the new API:
 * The notifier API is changed so that what was previously global state
 is now encapsulated in a Notifier object. This object also includes
 the publisher_id and has error()/info()/etc. methods rather than
 just notify().
 * The notify_decorator() helper wasn't carried across to the new API
 because its semantics are a bit weird. Something along these lines
 could be added in future, though.
 * We use a fake Notifier implementation for tests because there's no
 API in oslo.messaging to actually get the notifications queued
 up in the fake notification driver, which is a bit dumb. However,
 this feels like the right thing to do anyway. We're not wanting
 to test oslo.messaging.Notifier itself, but rather we want to test
 how we call it.
blueprint: oslo-messaging
Change-Id: I262163c7e05e6a6fb79265e904ce761fc3ac5806

Before updating security group rules, we need to make sure that
the info cache is up-to-date. Without this source groups are not
updated properly. This was a regression introduced in commit
85aac04704 which fixed a potential
DOS using source groups.
Fixes bug 1216720
Change-Id: I6b5115df53f2e159ea506ef966cd49cedd35f83d

The following commit(I5b37fa0bb19683fe1642fd81222547d4a317054e) have
not been merged to v3 tree now, because the commit was merged to the
existing api after porting flavors.py to v3 tree.
 commit b65d506a5f
 Author: Russell Bryant <rbryant@redhat.com>
 Date: Thu Jun 27 21:00:05 2013 +0000
 Make flavors is_public option actually work
This patch ports the commit to v3 tree.
Partially implements blueprint nova-v3-api
Change-Id: I3c7f11c53594118456d0cd62eb1ddf74634b77c3

This file was not properly git-add'd to commit:
 f2252de974
Related to blueprint compute-api-objects
Change-Id: Ibd25f4479d49f456bcb49e3eb003edf3d4b2b334

Each object with a list duplicated the _make_list() method in its
own module. This removes that duplication and adds a generalized
helper in objects/base.py. The instance object still uses its own
because it has to do a bunch of other stuff in the loop for
efficiency.
Change-Id: Ic910f39087ebc167b2b930979f7951116caf8598