On 06/05/2012 05:35 PM, Russell Bryant wrote: > On 06/05/2012 05:25 PM, Mark Washenberger wrote: >> >> >> "Mark McLoughlin" <mar...@redhat.com> said: >> >>> On Tue, 2012-06-05 at 12:21 -0400, Mark Washenberger wrote: >>>>> http://wiki.openstack.org/CommonLibrary#Incubation >>>> >>>> Once an api is in incubation, if you make a change to it, you are >>>> expected to update all the other openstack projects (not just core >>>> projects?) to make them work with the new api. Am I understanding this >>>> requirement correctly? >>> >>> Yes, pretty much. The alternative is that you don't make backwards >>> incompatible API changes. >> >> ... >> >>> >>> What alternative strategy are you suggesting? That if glance, quantum, >>> cinder and ceilometer want to re-use Nova's RPC code, they should >>> copy-and-paste it and hack it to their needs? >> >> I don't think our only options here are immediate adoption and relative >> chaos. >> >> Here's what I would like to see: >> >> Quantum, cinder, and ceilometer get together, recognize a shared need >> for rpc, acknowledge the successes and failures of the nova.rpc library, >> and create a better implementation with eventual adoption by Nova kept >> in mind. >> >> Doesn't that sound better? This approach seems much nicer to me, >> because I believe that code reuse is likely to be detrimental unless >> the code we're talking about was created with reuse and generality >> in mind. Since I find that suggestion implausible regarding nova.rpc >> in particular, I think we will do better overall avoiding its wider >> adoption. >> >> Please, forgive me if I'm being drawn in falsely by the allure of better >> code. Code structure and quality *is* something I obsess about. But I >> appreciate the need to be practical in the short term as well, if I am >> not always the best at articulating it. The agreement from various >> quarters about the problems with the current nova.rpc gave me hope >> that we could craft a better rpc library without too much delay, even >> if I myself can only contribute in a small way to that effort. > > That all sounds nice in theory, but like you alluded to here, who > specifically is going to sign up to do that? I can finish the move of > the current code (I have it ready to propose, actually), but I have > other things I should work on after that. > > How about the stakeholders interested in using this code in other > projects? Do you want the current code in now (with the likelihood of > having to adapt to some API changes later), or would you like to get > together and work on something new? If so, I'll just toss the proposal > of the current code for common and let someone else drive the new thing > in instead. >
By the way, the move of the current code is "ready" if we agree to proceed with it: https://review.openstack.org/#/c/8206/ -- Russell Bryant _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
