> 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.
That sounds good, especially during the early parts of incubation. > In the absence of someone appearing with that new idealised RPC API, I > think it's reasonable for Russell to proceed with his approach. Looking more closely at Russell's improvements, and thinking about the big changes I think we ought to make, it seems he's done a lot of the good work already. I would like for us to kick the global and C-style polymorphism habits in rpc, but I guess the best I can do is try to add these changes after its in common. Sorry if this has already been posted somewhere and I just can't find it, but is there an openstack common weekly meeting where you guys talk about your blueprints and determine what is going into common and in what form? I think I can be less disruptive if I'm involved in these discussions much earlier. "Mark McLoughlin" <mar...@redhat.com> said: > 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 > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
