Open Stack

> On Nov 10, 2014, at 4:30 PM, Angus Salkeld <asalkeld at mirantis.com> wrote:
> 
> Hi all
> 
> I just wanted to make sure we are all under the same understanding of the outcomes and what the next steps for the versioned objects session are.
> 
> 1. There is a lot of interest in other projects using oslo versioned objects and it is worth progressing with this (https://review.openstack.org/#/c/127532 <https://review.openstack.org/#/c/127532>).
> 2. jpipes and jharlow suggested experimenting/investigating google protocol buffers (https://developers.google.com/protocol-buffers/) <https://developers.google.com/protocol-buffers/%29> instead of  the custom serialization and version code. This *could* be an implementation detail, but also could make the adoption by nova more complicated (as it has a different mechanism in place).
> 3. vish brought up one draw back of versioned objects: the difficulty in cherry picking commits for stable branches - Is this a show stopper?.
> 
> Next steps:
> - Jay suggested making a second spec that would lay out what it would look like if we used google protocol buffers.
> - Dan: do you need some help in making this happen, do we need some volunteers?
> - Are there any other concrete things we can do to get this usable by other projects in a timely manner?
> 
> Regards
> Angus

I am personally very interested in seeing what the spec for adopting protobuf ends up looking like in comparison to the current Nova implementation. The main reason is that there is already a fairly well driven mechanism in place to utilize the objects across different languages. This would allow for better consumption of any/all notifications from outside of the OpenStack ecosystem as well as cases (such as tokens) that might legitimately need to evolve the format in the longer-term without breaking *everything*. I also think that it would largely be possible to provide a way to wrap the current Nova object model into protobuf as a conversion/transition plan.

This doesn’t discount that protobuf may in-fact not be a good fit for our use cases and the Nova model does have some reasonable drive-time on it. It very well might be a good solution for all the projects.

Regarding stable patches, largely if the object is versioned differently it would be more difficult to back port a change. I, however, am going to hazard a guess that most of the issues are not directly revolving around the serialization/deserialization code (nor the data directly driven by it) meaning that the incremental difference in back port headaches would be relatively minor. In short, I think breaking the hard-tie between the underlying storage model and the in-memory/serialization mechanism would be good for all of the projects.

Jay/Dan/Angus, please let me know if I can be any help with exploring protobuf.

Cheers,
Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141111/748f6ce6/attachment.html>