On Nov 13, 2014, at 12:38 AM, Flavio Percoco <fla...@redhat.com> wrote:

> On 12/11/14 15:22 -0500, Doug Hellmann wrote:
>> The oslo.messaging session at the summit [1] resulted in some plans to 
>> evolve how oslo.messaging works, but probably not during this cycle.
>> First, we talked about what to do about the various drivers like ZeroMQ and 
>> the new AMQP 1.0 driver. We decided that rather than moving those out of the 
>> main tree and packaging them separately, we would keep them all in the main 
>> repository to encourage the driver authors to help out with the core library 
>> (oslo.messaging is a critical component of OpenStack, and we’ve lost several 
>> of our core reviewers for the library to other priorities recently).
>> There is a new set of contributors interested in maintaining the ZeroMQ 
>> driver, and they are going to work together to review each other’s patches. 
>> We will re-evaluate keeping ZeroMQ at the end of Kilo, based on how things 
>> go this cycle.
> I'd like to thank the folks that have stepped up for this driver. It's
> great to see that there's some interest in cleaning it up and
> maintaining it.
> That said, if at the end of Kilo the zmq driver is still not in a
> usable/maintainable mode, I'd like us to be more strict with the plans
> forward for it. We asked for support in the last 3 summits with bad
> results for the previous 2 releases.
> I don't mean to sound rude and I do believe the folks that have
> stepped up will do a great job. Still, I'd like us to learn from
> previous experiences and have a better plan for this driver (and
> future cases like this one).
>> We also talked about the fact that the new version of Kombu includes some of 
>> the features we have implemented in our own driver, like heartbeats and 
>> connection management. Kombu does not include the calling patterns 
>> (cast/call/notifications) that we have in oslo.messaging, but we may be able 
>> to remove some code from our driver and consolidate the qpid and rabbit 
>> driver code to let Kombu do more of the work for us.
> This sounds great. Please, whoever is going to work on this, feel add
> me to the reviews.
>> Python 3 support is coming slowly. There are a couple of patches up for 
>> review to provide a different sort of executor based on greenio and 
>> trollius. Adopting that would require some application-level changes to use 
>> co-routines, so it may not be an optimal solution even though it would get 
>> us off of eventlet. (During the Python 3 session later in the week we talked 
>> about the possibility of fixing eventlet’s monkey-patching to allow us to 
>> use the new eventlet under python 3.)
>> We also talked about the way the oslo.messaging API uses URLs to get some 
>> settings and configuration options for others. I thought I remembered this 
>> being a conscious decision to pass connection-specific parameters in the 
>> URL, and “global” parameters via configuration settings. It sounds like that 
>> split may not have been implemented as cleanly as originally intended, 
>> though. We identified documenting URL parameters as an issue for removing 
>> the configuration object, as well as backwards-compatibility. I don’t think 
>> we agreed on any specific changes to the API based on this part of the 
>> discussion, but please correct me if your recollection is different.
> I prefer URL parameters to specify options. As of now, I think we
> treat URL parameters and config options as two different things. Is
> this something we can change and "translate" URL parameters to config
> options?

I'd rather go completely with config and have something like 
https://review.openstack.org/#/c/130047/ which allows for users that don't have 
a CLI accessible (aka from other libraries) to actually use oslo.messaging (for 
ex, taskflow). I believe url parameters could work, its just that config 
already provides typing (ints, bools, lists) and descriptions and urls have 
none of this (they also don't have a nested structure, aka grouping, which I 
believe some of oslo.messaging is using?).

> I guess if we get to that point, we'd end up asking ourselves: Why
> shouldn't we use just config options in that case?
> I think one - historical (?) - answer to that is that we once thought
> about not using oslo.config in oslo.messaging.

So would https://review.openstack.org/#/c/130047/ make that better?

A user that doesn't have access to oslo.config options would then just have to 
provide a dictionary of equivalent options. As described in that review (and 
pretty obvious) is that not everyone in the python world uses oslo.config 
options and therefore we need/must have a compatiblity layer for users to use 
if they so choose.

This could then look like the following when used: 

In all honesty I just want one way that works, if thats URLs or config (IMHO 
the only way config will actually work is if we have a interface in oslo.config 
like described in 130047 for people that want to use oslo.messaging that are 
not applications...) I don't care in the end. I just know that 2 ways (both 
seemingly second class citizens) is pretty crappy...

> Looking forward to have more feedback on this point, I unfortunately
> missed this session because I had to attend another one.
> Flavio
> -- 
> @flaper87
> Flavio Percoco
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to