Open Stack

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: sileht at sileht.net
irc: sileht