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]. 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.
[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