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
Unlike all object object save methods, Aggregate.save() returns an
aggregate object. This change removes the return to make it consistent
with other objects.
Change-Id: I2179bc90ae92dd3a4f739aae2802a417bd7e2d9d
This change adds the get_by_metadata_key function to the AggregateList object
and the aggregate_get_by_metadata_key function to the DB API.
Previously, the only DB API function available for finding aggregates matching
a metadata key returned a dictionary of aggregated metadata. The
aggregate_get_by_metadata_key function returns all rows matching the specified
metadata key, and is called by the existing aggregate_host_get_by_metadata_key
DB API function.
The get_by_metadata_key function returns a list of Aggregate objects matching
the specified metadata key.
Related to blueprint compute-manager-objects-juno
Change-Id: If50c9f613dd192ab44577f26a81dd5b40e3a7af7
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
Remove duplicate code updates.pop('id', None) in create() function.
Because if self.obj_attr_is_set('id'):
raise exception.ObjectActionError(action='create',
reason='already created')
already make sure object doesn't have 'id' values, which means that
'id' won't appear in updates.
Change-Id: I582ef8857b32c07ea8ba1eb5fc1e64516110f3ce
When update metadata for a host aggregation, all of the values will
be in the variable of "updates", if remove metadata, the format would
be {"foo": None, "bar": None}; If adding metadata, the format would
be {"foo": "foo1", "bar": "bar1"}.
The current logic of update_metadata() is as following:
1) Get all metadata from variable "updates".
2) Traverse updates to see which values are new added and which needs
to be removed. For the new added values, put the metadata to
variable "to_add"; for the values which need to be removed, just
remove them from metadata.
3) Set the values of variable "to_add" as payload metadata.
The above logic will make the values which was removed from metadata
cannot be in payload, this caused the third party receiver cannot know
which metadata was removed.
The fix was always using the values from variable "updates" as the
metadata for payload as it include values removed and new added.
Change-Id: I7b78795e325f52cfb9c24eabd9ef42990666c02d
Closes-Bug: #1269684
The patch is to remove id when it was set before creating an aggregate
in objects, and check if the aggregate exists before it is created.
Related to blueprint icehouse-objects.
Change-Id: I0d7c5c5da9a93e52c7fee9eee7df80d2f460593e
Right now, a client declares its supported version of a given object
automatically in the remoted calls it makes to conductor. However,
in the case of things like InstanceList.get_by_foo(), they are
reporting the version of their InstanceList object, not their
Instance object. Conductor fills a version-matching InstanceList
object with brand new Instance objects, which the client, of course,
barfs on.
There may be a better way to handle this going forward, but for now,
stop the bleeding by requiring a version bump to the corresponding
List object whenever the object type it contains takes a version
bump. This adds a test to validate that all the objects registered
have a suitable mapping for the current version in the tree.
Since this actually caused a breakage in the Instance object
recently, this also bumps the InstanceList version so that
conductors running this commit (or later) will properly send
version 1.9 Instance objects to Havana clients and version 1.10+
to newer ones.
Change-Id: I2668dead4784fbd0411d1b6372a9a8006eeb2e84
Related-Bug: #1258256
Closes-Bug: #1254902
The object infrastructure has a concept of an object name, which
is what we use to determine if something implements a particular
thing, and it is how we look up object classes when we
deserialize them. Since many objects will eventually reference
each other, we should be using their names to determine
compatibility, not their classes.
Related to blueprint structured-object-fields
Change-Id: I2edb8b8475662ad25e9f3319ce5e44317a2d0547
This simply adds the ability to pass the key attribute to the
by-host lookup for aggregates.
Related to blueprint compute-manager-objects
Change-Id: I7651bc1470845b1e3586aa3616809bdf2ef2b4a2
Originally, all of the objects used str() to specify string type
attributes. This prevents the use of unicode values. A previous
patch errantly updated the utility function without bumping all
of the affected objects' versions. This does that, and also
fixes the issue for bare str() attributes.
Change-Id: Iad83589d399309b95c32813a1a660a12e571066b
Closes-bug: 1221346
Almost every object thus far has done this:
changes = {}
for key in self.obj_what_changed():
changes[key] = self[key]
to get a dict of updates to apply to the database. This patch adds
that as part of the base object and makes every place that does
the above to just use that.
Change-Id: I847f5d35181b0305668b107f86faa164e71c3375
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
Creates a new DBObjectMixin class for DB-backed objects to use. This
allows us to create non-DB-backed objects without having the common DB
fields automagically added to them.
Related to blueprint unified-object-model
Change-Id: Iaf2d8500505e9acdbffffb1d4bd3db0870ae82a3
