Open Stack

> 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" <markmc at redhat.com> said:

> On Tue, 2012-06-05 at 17:25 -0400, 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.
> 
> 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>