Michael Krotscheck wrote:
On Thu, Aug 6, 2015 at 10:08 AM Mehdi Abaakouk <sil...@sileht.net
<mailto:sil...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
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
