On Tue, Nov 25, 2014 at 7:06 AM, Jay Pipes <jaypi...@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:
>>>
>>> https://review.openstack.org/#/c/134623/
>>>
>>>  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?
>>>>
>>>
>>> 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
> this.
>
> 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.

-Angus


>
> Best,
> -jay
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to