[openstack-dev] [all] Versioned objects cross project sessions next steps
asalkeld at mirantis.com
Mon Nov 24 22:11:13 UTC 2014
On Tue, Nov 25, 2014 at 7:06 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> On 11/24/2014 03:11 PM, Joshua Harlow wrote:
>> Dan Smith wrote:
>>> 3. vish brought up one draw back of versioned objects: the difficulty in
>>>> cherry picking commits for stable branches - Is this a show stopper?.
>>> After some discussion with some of the interested parties, we're
>>> planning to add a third .z element to the version numbers and use that
>>> to handle backports in the same way that we do for RPC:
>>> 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
>>> I'm not planning to look into this, especially since we discussed it a
>>> couple years ago when deciding to do what we're currently doing. If
>>> someone else does, creates a thing that is demonstrably more useful than
>>> what we have, and provides a migration plan, then cool. Otherwise, I'm
>>> not really planning to stop what I'm doing at the moment.
>>> - Are there any other concrete things we can do to get this usable by
>>>> other projects in a timely manner?
>>> To be honest, since the summit, I've not done anything with the current
>>> oslo spec, given the potential for doing something different that was
>>> raised. I know that cinder folks (at least) are planning to start
>>> copying code into their tree to get moving.
>>> I think we need a decision to either (a) dump what we've got into the
>>> proposed library (or incubator) and plan to move forward incrementally
>>> or (b) each continue doing our own thing(s) in our own trees while we
>>> wait for someone to create something based on GPB that does what we want.
>> I'd prefer (a); although I hope there is a owner/lead for this library
>> (dan?) and it's not just dumped on the oslo folks as that won't work out
>> so well I think. It'd be nice if said owner could also look into (b) but
>> that's at there own (or other library supporter) time I suppose (I
>> personally think (b) would probably allow for a larger community of
>> folks to get involved in this library, would potentially reduce the
>> amount of custom/overlapping code and other similar benefits...).
> I gave some comments at the very end of the summit session on this, and I
> want to be clear about something. I definitely like GPB, and there's
> definite overlap with some things that GPB does and things that
> nova.objects does.
> That said, I don't think it's wise to make oslo-versionedobjects be a
> totally new thing. I think we should use nova.objects as the base of a new
> oslo-versionedobjects library, and we should evolve oslo-versionedobjects
> slowly over time, eventually allowing for nova, ironic, and whomever else
> is currently using nova/objects, to align with an Oslo library vision for
> So, in short, I also think a) is the appropriate path to take.
Yeah, my concern with "(b)" is the time it will take for other projects to
get to use it, esp. since no one is
jumping to take the work on.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev