> On Nov 10, 2014, at 4:30 PM, Angus Salkeld <[email protected]> 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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
