← Back to team overview

openstack team mailing list archive

Re: cfg usage - option registration, global objects

 

On Tue, Jun 5, 2012 at 1:00 PM, Mark McLoughlin <markmc@xxxxxxxxxx> wrote:
> On Tue, 2012-06-05 at 12:48 -0400, Duncan McGreggor wrote:
>> +1 :-)
>
> In all seriousness - Mark made two separate points. Which one are you
> top-posting a +1 to?

Ah, sorry -- I'll be more explicit. Condensing my previous comments:
if globals are in fact going to be used, I'm 100% in favor of a
solution that defines an API around the use of globals such that there
is a canonical way to access them and the proper means of accessing
them is well documented in the various functions/methods that provide
such access :-)

d

>> On Fri, Jun 1, 2012 at 10:37 AM, Mark Washenberger
>> <mark.washenberger@xxxxxxxxxxxxx> wrote:
>> > Hi Mark,
>> >
>> > Please forgive the top-posting! I always get way too wordy with
>> > inline replies.
>
> <point 1>
>
>> > Regarding configuration, I think there is another option I'd like us
>> > to adopt. We should implement the code as in your option #1, but then
>> > implement convenience factories that give the appearance of option #3
>> > or #2, or both, you pick. From your examples it might look something
>> > like this:
>> >
>> >    class Connection(object):
>> >
>> >        def __init__(self, broker_hostname, broker_port):
>> >            self.cnx = self.connect(broker_hostname, broker_port)
>> >
>> >        def cast(self, topic, msg):
>> >            self.cnx.cast(topic, msg)
>> >
>> >    def connection_from_global_conf():
>> >        return Connection(CONF.broker_hostname, CONF.broker_port)
>> >
>> > I think its pretty necessary that we don't do option #3 directly.
>> > There are some important use cases to consider, like migrating from
>> > one rpc implementation to another where you might want an adapter
>> > that can relay messages from one to the other. Also, cells with
>> > kombu at least requires that one process be able to talk to multiple
>> > brokers.
>
> </point 1>
>
> <point 2>
>
>> > Regarding incubation, I suppose I am confused. At what point during
>> > incubation do other projects start to use the shared library? I would
>> > imagine the answer to be "after incubation" but it sounds like there
>> > are several projects very eager to adopt rpc as soon as it lands in
>> > openstack common, even before incubation is complete.
>> >
>> > If incubation happens before the calcifying effects of shared use
>> > set in, then it sounds like a great place to address the other
>> > rpc-specific concerns we've talked about. Otherwise I guess we're
>> > stuck where I thought we were, where the bar needs to be set pretty
>> > high to initially land in os-common.
>
> </point 2>
>
> Cheers,
> Mark.
>


References