On 11/24/15 at 11:19am, Ryan Rossiter wrote:
On 11/24/2015 8:35 AM, Andrew Laski wrote:
On 11/24/15 at 10:26am, Balázs Gibizer wrote:
<snip>
I think see your point, and it seems like a good way forward.
Let's turn the black list to
a white list. Now I'm thinking about creating a new Field type
something like
WhiteListedObjectField which get a type name (as the ObjectField)
but also get
a white_list that describes which fields needs to be used from
the original type.
Then this new field serializes only the white listed fields from
the original type
and only forces a version bump on the parent object if one of the
white_listed field
changed or a new field added to the white_list.
What it does not solve out of the box is the transitive
dependency. If today we
Have an o.vo object having a filed to another o.vo object and we
want to put
the first object into a notification payload but want to
white_list fields from
the second o.vo then our white list needs to be able to handle
not just first
level fields but subfields too. I guess this is doable but I'm
wondering if we
can avoid inventing a syntax expressing something like
'field.subfield.subsubfield'
in the white list.
Rather than a whitelist/blacklist why not just define the schema of
the notification within the notification object and then have the
object code handle pulling the appropriate fields, converting
formats if necessary, from contained objects. Something like:
class ServicePayloadObject(NovaObject):
SCHEMA = {'host': ('service', 'host'),
'binary': ('service', 'binary'),
'compute_node_foo': ('compute_node', 'foo'),
}
fields = {
'service': fields.ObjectField('Service'),
'compute_node': fields.ObjectField('ComputeNode'),
}
def populate_schema(self):
self.compute_node = self.service.compute_node
notification = {}
for key, (obj, field) in schema.iteritems():
notification[key] = getattr(getattr(self, obj), field)
Then object changes have no effect on the notifications unless
there's a major version bump in which case a SCHEMA_VNEXT could be
defined if necessary.
To be fair, that is basically a whitelist ;) [1].
Heh, fair point :)
But if we use this
method, don't we lose a lot of o.vo's usefulness? When we serialize,
we have to specifically *not* use the fields because that is the
master sheet of information that we don't want to expose all of.
Either that or we have to do the transform as part of the
serialization using the schema, which you may be aiming at, I might
just be looking at the snippet too literally.
I was thinking along the lines of doing the transform as part of
serialization. But really I wasn't thinking that serialization as it's
done for RPC is needed at all. I'm not expecting notification consumers
to hydrate Nova objects from whatever is emitted, just receive a
standard JSON payload that they can use. So I wouldn't expect
notification code to call obj_to_primitive() but perhaps a new emit()
method which will do the transform to the schema.
I think we're all on a similar page though and perhaps we can continue
the discussion on a review to nail down details.
[1] http://www.smbc-comics.com/index.php?id=3907
--
Thanks,
Ryan Rossiter (rlrossit)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
