Open Stack

Michael Krotscheck wrote:
> On Thu, Aug 6, 2015 at 10:08 AM Mehdi Abaakouk <sileht at sileht.net
> <mailto: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.

It only relies on the rest of the config object to 'magically' fetch the 
values of attributes from somewhere, organize them into some grouping, 
and perform the right type checking/conversion (type checking in python, 
woah), and the magic of digging into help strings instead of docstrings 
(which means the generated code docs of config object using components 
either have to replicate the help string or do something else)... but 
point taken ;)

(I've always preferred APIs that use the standard things u see in python 
to document arguments, parameter types, what there usage is; yes I know 
the history here, just saying this is just another different kind of magic).

>
>     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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev