> On Nov 10, 2014, at 4:30 PM, Angus Salkeld <asalk...@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 

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

OpenStack-dev mailing list

Reply via email to