Open Stack

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)