On Nov 13, 2014, at 3: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). Absolutely. It seems that each time we ask for help, a new set of contributors step up. This is, I think, the third cycle where that has been the case? Three being widely recognized as a magic number (check your retry loops), either “the third time’s the charm” or “three strikes and you’re out” may apply in this case as well. :-) Of course, their success depends a great deal on *us* to review the changes, as well. > >> >> 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 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. That’s true, and another reason was to handle cases like an arbitrary number of connections (ceilometer needed more than one, though I don’t remember if it was truly arbitrary). Normally the messaging settings in the config file are in one group, and the application doesn’t know the name of the group. If we use the config file to pull in all of the settings the application would need to know the group name(s) because the options themselves are (a) not part of the API and (b) not necessarily registered on the global config object (the library might use the config filter to hide the option settings). I think we decided that URLs were less ugly than exposing the config group names, though they do introduce some other complexity. As Josh points out in his message in this thread, the thing parsing the URL to get the options has to do validation similar to what oslo.config is already doing (type, range, etc.). We talked about providing some sort of API in oslo.config that would take a URL, parse it, and treat the parameters as though they were options. We didn’t go so far as to design what that API might look like, and it wasn’t clear if it was a good idea or not. Doug > > 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
