Hi,
Also to support some of the newer services that don't use paste i
think we should absolutely make it so that the CONF object is passed
to middleware rather than sourced globally. I think gnochhi and zaqar
both fit into this case.
For example, Gnocchi doesn't use paste, deployer adds middlewares like
this:
[api]
middlewares =
oslo_middleware.request_id.RequestId,oslo_middleware.cors.CORS,keystonemiddleware.auth_token.AuthProtocol
Of course because of the current issue, we browse the pipeline to pass
the correct options to
keystonemiddleware.auth_token.AuthProtocol, to make it works. My change
allows to remove this workaround.
The problem i see with what you are saying is that it is mixing
deployment methodologies in a way that is unintended. Paste is
designed to allow deployers to add and remove middleware independent
of configuring the service. This means that at paste time there is no
CONF object unless it's globally registered and this is why most
middlewares allow taking options from paste.ini because if you don't
have global CONF then it's the only way to actually get options into
the middleware.
My change adds a new way that doesn't use global CONF object but still
read options
from the application configuration file.
Fixing this problem is always where i loose enthusiasm for removing
global CONF files.
With my solution, if all applications update they paste.ini
configuration, we
can remove the global CONF from keystonemiddleware and only relies on
options loaded
via paste or via the local oslo.cfg object.
keystonemiddleware become like most middlewares and does not depend
anymore on the application.
(If you want that I can write a patch to deprecate usage of global CONF
object
once my change is merged, and update paste.ini of other projects)
From a developer perspective I feel the solution is for us to
reconsider how we deploy and configure middleware. If you are using
paste those pieces of middleware should each be able to be configured
without any integration with the service underneath it. Otherwise if
your service needs a piece of middleware like auth_token middleware to
operate or relies on oslo.config options like cors then that is not
something that should be controlled by paste.
From a deployer perspective there is no great answer i just want
everything to be in oslo.config.
Yeah, that's the goal, whatever the app uses global or not, uses paste
or not, etc...
for the deployer, the configuration of middlewares are in oslo.config.
Equally from a deployer perspective this wasn't an issue until aodh
(et al) decided to remove the global CONF object which developers from
all the projects hate but live with. I don't mean to imply we
shouldn't look at better ways to do things, but if you're main concern
is deployers the easiest thing we can do for consistency is add back
the global CONF object or remove paste from aodh. :)
I will be sad to readd the global CONF object (removing paste is not
really an option for us I think).
Cheers,
---
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
