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: http://paste.ubuntu.com/8982657/ 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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
