nova/db/__init__.py was importing * from nova.db.api. This meant that
any time any code anywhere within the nova.db package was imported
then nova.db.api was too, leading to a cascade of imports that may
not have been desired. Also, in general, code in __init__.py is a pain.
Therefore, this change adjusts code that so that either:
* nova.db.api is used directly
* nova.db.api is imported as 'db'
In either case, the functionality remains the same.
The primary goal of this change was to make it possible to import the
model files without having to import the db api. Moving the model files
to a different place in the directory hierarchy was considered, but
given that "code in __init__.py is a pain" this mode was chosen.
This looks like a very large change, but it is essentially adjusting
package names, many in mocks.
Change-Id: Ic1fd7c87ceda05eeb96735da2a415ef37060bb1a
This adds a destroy() method for VirtualInterface which has not been
required before but is now.
Change-Id: Ie00f52153a816049f8efcc9aa8071371ce0b7e5a
Related-Bug: #1602357
Neutron does not require global uniqueness for MAC addresses, but
nova-network did. Since VirtualInterface was designed for n-net and
is still used to enforce its requirements for such uniqueness, we can
simply use the extra space in the address field to namespace our
MAC address in neutron to avoid the constraint. We can hide this
behavior in the object so nothing else needs to know, and we have
255 characters in the field, which is enough for a uuid and a mac
address to fit.
Closes-Bug: #1597770
Change-Id: I23480d98ca339c119100e8ab7df633ed8b80b1e9
I always have to check if the VirtualInterface.address
field is an IP or a MAC address, so add a comment about
what it is.
Change-Id: I2fd31f2bcc00a0bba15b625c2d97f7d50e40e929
Adding a save method to the virtual_interface object
and an update method to its database model.
Partially implements blueprint virt-device-role-tagging
Co-authored-by: Artom Lifshitz <alifshit@redhat.com>
Change-Id: I52673fc297cb578995be5c7a075c5693b0793bf5
This patch series adds the ability for a user to specify a tag to be
applied to a network interface or a disk when booting an instance.
This tag is then exposed through the metadata API. For example, a user
boots a VM with two network interfaces. One is connected to a private
network, the other to the public Internet. There is currently no
direct way to tell which interface is which. Specifying tags allows
the user to distinguish between the two interfaces.
This patch contains the database migration to add a 'tag' column to
the virtual_interfaces and block_device_mapping tables as well as the
corresponding change to the VirtualInterface and BlockDeviceMapping
objects.
Implements: blueprint virt-device-role-tagging
Co-authored-by: Vladik Romanovsky <vromanso@redhat.com>
Change-Id: Ic8be3de4e970116772f9b6ce01c55e26b829e6cb
In Liberty, we converted to using the manifest-based class
action and backport methods, which no longer rely on these
object relationship maps. They provide a full manifest of
client-side versions with each call, which is far more
robust than us trying to hand-edit these mappings (which
we get incorrect a lot).
Since we're now in Mitaka, we can drop compatibility with
clients that don't make the version-manifest calls. Those
have also been deprecated in oslo.versionedobjects.
Change-Id: Iea8b6348e3b01aaa335ec5408f07826f1e758d20
cleanup subclassing on NovaObjectDictCompat and fix subsequent
tests and code associated with nova/objects/virtual_interface.py
Due to the exhaustive nature of changes, the cleanup is done
one object at a time.
This is the second patch of the series.
There shall be more patches to follow for other objects.
Related to blueprint liberty-objects
Change-Id: Ia66bea59828beaeb8d79348331619d0b848c1a3f
List objects used to use child_versions, which was tested in a more
shallow way than test_relationships() tests obj_relationships. This
change moves over all list classes to use obj_relationships (and
therefore are now tested in test_relationships() with all other
objects).
Change-Id: I334dba243de45bf11ccb5ab55e2aa8390fe9d8c2
Closes-Bug: #1470154
In oslo.versionedobjects, the registry is opt-in instead of implicit.
This patch sets the stage for moving to that by defining a no-op
registry with a compatible register method so that we can go ahead and
decorate the object classes and then move the registry underneath them.
Related to blueprint use-oslo-objects
Change-Id: Iddc68a2d8a9b103621bc60a7426fe495edf80aad
This is the final step in removing the context parameter from the
signature of a remotable method.
This includes a change of most of the object hashes, without version
bumps. That's because the hashing algorithm is just looking for changes
in things like a call signature, in order to signal that a version bump is
required. Since context is in the signature, removing it triggers the
alert. However, context is not _actually_ part of the on-the-wire API,
as it is stripped out on the caller side, and re-added on the callee side
(hence why we're making this change in the first place). If the test had
been uuber-pedantic to exclude context from consideration, then the hashes
would not be changing here, but alas.
In short, the hash changes are false alarms and do not mean we need
version bumps for all the things.
Related to blueprint kilo-objects
Change-Id: I89464c0ab7e6e0d84e677b9a69a86468727b6438
This removes the use of the context parameter in remotable methods
in these objects. This is a precursor to actually removing the
context from the call, but we need to remove dependence on the
argument first. Remotable methods should be using the bundled object
context.
Related to blueprint kilo-objects
Change-Id: I8d040a03d0daa314e8fc47747ba8c7735fd744d0
The XXXList() classes only ever have a single 'objects' attribute
and this is never directly accessed as a dict key, instead all
callers use it in list context. Thus the dict compat support can
be removed from all these objects
Change-Id: I3f8d49d25b99dd0a498dfaad705c6332908cb72f
The dict compat support in NovaObject is useful for incrementally
converting existing code over to use objects. Any brand new objects
though have no reason to support dictionary access, so there should
be a way to disable this compat mode.
This moves all the dict compat support methods out of NovaObject,
to a new class NovaObjectDictCompat. All existing objects are
updated to add this new class as a mix-in parent.
In future any completely new objects (ie ones which aren't being
used to converted existing code from dict instances) should avoid
inheriting from NovaObjectDictCompat. Existing objects should
also have this parent class removed once all callers are audited
and/or updated to ensure they do not require dict compat.
Change-Id: I03f93f0c40df6f5f7df9cefe28dff900c22294c9
The object code itself should not explicitly reference its own objects,
as objects could be subclassed.
Also: There were a few objects that had their own __init__()s that
didn't support accepting 'context' or kwargs. At some point here, we
should also require that context is passed when instantiating the
objects. So, I added the (currently optional) context argument on some
object instantiations near the places I was touching.
Partial-Blueprint: object-subclassing
Change-Id: Icf631c770e347b4bb32999c4ba2431d1db49e11c
Add new objects: VirtualInterface and VirtualInterfaceList. These are
needed for converting nova-network over to use objects.
Part of blueprint nova-network-objects
Change-Id: Idab38a2a9bd8737fcc8e112759c539b7ebad4df9
Chris Dent