Hi,
I want to share with you some problems I have recently encountered with
openstack middlewares and oslo.config.
The issues
----------
In project Gnocchi, I would use oslo.middleware.cors, I have expected to
just put the name of the middleware to the wsgi pipeline, but I can't.
The middlewares only works if you pass the oslo_config.cfg.ConfigOpts()
object or via 'paste-deploy'... Gnocchi doesn't use paste-deploy, so
I have to modify the code to load it...
(For the keystonemiddleware, Gnocchi already have a special
handling/hack to load it [1] and [2]).
I don't want to write the same hack for each openstack middlewares.
In project Aodh (ceilometer-alarm), we recently got an issue with
keystonemiddleware since we remove the usage of the global object
oslo_config.cfg.CONF. The middleware doesn't load its options from the
config file of aodh anymore. Our authentication is broken.
We can still pass them through paste-deploy configuration but this looks
a method of the past. I still don't want to write a hack for each
openstack middlewares.
Then I have digged into other middlewares and applications to see how
they handle their conf.
oslo_middlewarre.sizelimit and oslo_middlewarre.ssl take options only
via the global oslo_config.cfg.CONF. So they are unusable for application
that doesn't use this global object.
oslo_middleware.healthcheck take options as dict like any other python
middleware. This is suitable for 'paste-deploy'. But doesn't allow
configuration via oslo.config, doesn't have a strong config options
type checking and co.
Zaqar seems got same kind of issue about keystonemiddleware, and just
write a hack to workaround the issue (monkeypatch the cfg.CONF of
keystonemiddleware with their local version of the object [3] and then
transform the loaded options into a dict to pass them via the legacy
middleware dict options [4]) .
Most applications, just still use the global object for the
configuration and don't, yet, see those issues.
All of that is really not consistent.
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.
But keystonemiddleware, oslo.middleware.cors,... are supposed to be wsgi
middlewares, something that is independant of the app.
And this is not really the case.
From my point of view and what wsgi looks like generally in python, the
middleware object should be just MyMiddleware(app, options_as_dict),
if the middleware want to rely to another configuration system it should
do the setup/initialisation itself.
So, how to solve that ?
------------------------
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
* 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.
* 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.
* 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.
I really think all our middlewares should be consistent:
* to be usable by all applications without enforcing them to write crap around
them.
* and to made the deployer life easier.
Possible solution:
------------------
I have already started to work on something that do all of that for all
middlewares [5], [6]
The idea is, the middleware should create a oslo_config.cfg.ConfigOpts()
(instead of rely on the global one) and load the configuration file of the
application in. oslo.config will discover the file location just with the
name of application as usual.
So the middleware can now be loaded like this:
code example:
app = MyMiddleware(app, {"oslo_config_project": "aodh"})
paste-deploy example:
[filter:foobar]
paste.filter_factory = foobar:MyMiddleware.filter_factory
oslo_config_project = aodh
oslo_config.cfg.ConfigOpts() will easly find the /etc/aodh/aodh.conf,
This cut the hidden links between middleware and the application
(through the global object).
And of course if oslo_config_project is not provided, the middleware
fallback the global oslo.config object.
The middleware options can still be passed via the legacy dict.
The backward compatibility is conserved.
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 ?
Cheers,
[1] https://github.com/openstack/gnocchi/blob/master/gnocchi/rest/app.py#L140
[2] https://github.com/openstack/gnocchi/blob/master/gnocchi/service.py#L64-L73
[3]
https://github.com/openstack/zaqar/blob/87fd1aa93dafb64097f731dbd416c2eeb697d403/zaqar/transport/auth.py#L63
[4]
https://github.com/openstack/zaqar/blob/87fd1aa93dafb64097f731dbd416c2eeb697d403/zaqar/transport/auth.py#L70
[5] https://review.openstack.org/#/c/208965/
[6] https://review.openstack.org/#/c/209817/
--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht
__________________________________________________________________________
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
