Open Stack

On Thu, Aug 6, 2015 at 10:08 AM Mehdi Abaakouk <sileht at sileht.net> wrote:

>
> Yes, but you can't use oslo.config without hardcode the loading the
> middleware to pass the oslo.config object into the application.
>

Yes, and that is intentional, because the use of global variables of any
sort is bad. They're unconstrained, there's no access control to guarantee
the thing you want hasn't been modified, and in the case of oslo.config,
they require initialization before they can be used.

Writing any kind of logic that assumes that a magic global instance has
been initialized is brittle. The pastedeploy wsgi chain is a perfect
example, because the application is only created after the middleware chain
has been executed. This leaves you with - at best - a malfunctioning piece
of middleware that breaks because the global oslo.config object isn't
ready. At worst it's a security vulnerability that permits bypassing things
like keystone.

Passing the config object is a _good_ thing, because it doesn't rely on
magic. Magic is bad. If someone looks at the code and says: "I wonder how
this piece of middleware gets its values", and they don't see the config
object being passed, they have to dig into the middleware itself to figure
out what's going on.


> I'm clearly on the operator side too, and I just try to find a solution to
> be able to use all middlewares without having to write code for each
> in each application and use oslo.config. Zaqar, Gnocchi and Aodh are
> the first projects that do to not use cfg.CONF and can't load many
> middlewares without writing code for each. When middleware should be just
> something that deployer enabled and configuration. Our middleware looks
> more like a lib than a middleware)
>

Sorry, but you're talking from the point of view of someone who wants to
"not have to write code for each". That's a developer. It's our job as
developers to write code until it's as easy as possible, and passing in a
config object is _dead simple_ in your application initialization.

Here's the thing. If the middleware is _optional_ like keystone auth, then
including it via paste.ini makes way more sense. In fact, keystone auth has
gone to great lengths to have no dependencies for that very same reason.
If, instead, the middleware is a feature that should ship with the service
- like CORS, or a simple caching layer - then it should be baked into your
application initialization directly.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150807/a28abe47/attachment.html>