On Thu, Aug 06 2015, Mehdi Abaakouk wrote: > This is confusing for developer to have some middlewares that need pre-setup, > enforce them to rely on global python object, and some others not. > This is confusing for deployer their can't do the configuration of middlewares > in the same way for each middlewares and each projects.
Agreed, this is a terrible design. > Do you agree: > > * all openstack middlewares should load their options with oslo.config ? > this permits type checking and all other features it provides, it's cool :) > configuration in paste-deploy conf is thing of past That sounds like a good idea. > * we must support local AND global oslo.config object ? > This is an application choice not something enforced by middleware. > The deployer experience should be the same in both case. Well, I guess if you support local you can anyway use the global as local. :) > * the middleware must be responsible of the section name in the oslo.config ? > Gnocchi/Zaqar hack have to hardcode the section name in their code, this > doesn't looks good. I'd think so. > * we must support legacy python signature for WSGI object, MyMiddleware(app, > options_as_dict) ? To be able to use paste for > application/deployer that want it and not break already deployed > things. Definitely agreed. > Possible solution: > ------------------ > > I have already started to work on something that do all of that for all > middlewares [5], [6] > […] > I have already tested that in Gnocchi and Aodh, and that solves all of my > issues. Remove all hacks, the application doesn't need special pre > setup. All our middleware become normal middleware but still can use > oslo.config. > WDYT ? I already +2 some of the patches, I think the approach is good and sane, and I honestly don't have anything better so thank you Mehdi. :) Cheers, -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
