openstack team mailing list archive

[Russell Bryant <rbryant@xxxxxxxxxx>]

On 06/05/2012 05:25 PM, 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. 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.

-- 
Russell Bryant