[Openstack] cfg usage - option registration, global objects

Mark Washenberger mark.washenberger at rackspace.com
Tue Jun 5 21:25:29 UTC 2012



"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.

Respectfully,
markwash







More information about the Openstack mailing list