Open Stack

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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev