[Openstack] cfg usage - option registration, global objects

Russell Bryant rbryant at redhat.com
Tue Jun 5 21:48:18 UTC 2012


On 06/05/2012 05:35 PM, Russell Bryant wrote:
> On 06/05/2012 05:25 PM, Mark Washenberger wrote:
>>
>>
>> "Mark McLoughlin" <markmc at 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




More information about the Openstack mailing list