On Tue, 2012-06-05 at 17:25 -0400, 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.
I should clarify this - I don't think someone improving an API in openstack-common absolutely must update all projects that use it, but I think he/she often will update the major users to make sure the new API works. But the reality is that projects which use openstack-common need to be prepared that someday they might re-sync with latest openstack-common using update.py and find the API has changed. > > 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. I think the summary is that you'd like (someone else?) to start from scratch on a new RPC API in openstack-common, whereas Russell has gone for the approach of taking Nova's RPC API and improving it iteratively. In the absence of someone appearing with that new idealised RPC API, I think it's reasonable for Russell to proceed with his approach. Cheers, Mark. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp