openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

On Tue, 2012-06-05 at 17:25 -0400, Mark Washenberger wrote:
> 
> "Mark McLoughlin" <markmc@xxxxxxxxxx> 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.