On Tue, Nov 25, 2014 at 7:06 AM, Jay Pipes <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
