<div dir="ltr"><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 22, 2015 at 2:43 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from Sean Dague's message of 2015-06-22 13:30:44 -0400:<br>
<div><div class="h5">> On 06/22/2015 01:15 PM, Michael Krotscheck wrote:<br>
> > Having _just_ done this, a couple of suggestions.<br>
> ><br>
> > - If the middleware is NOT optional - that is, it provides some kind of<br>
> > a fundamental component or specification of the API, like ETag caching,<br>
> > CORS, or DB Session management - then the middleware should be added<br>
> > during the app initialization routine, likely in the app factory. In<br>
> > this case, we have tight control over the initialization order, and can<br>
> > make sure that oslo.config is there first. Yay config.<br>
> ><br>
> > - If the middleware _is_ optional, then I really feel this problem is<br>
> > solved by pastedeploy's filter_factory pattern. It lets you define as<br>
> > many required parameters as you want, and spits back a middleware<br>
> > instance. That way you have the freedom to set whatever configuration<br>
> > options you want, or omit the middleware altogether.<br>
> ><br>
> > <a href="http://pythonpaste.org/deploy/#paste-filter-factory" rel="noreferrer" target="_blank">http://pythonpaste.org/deploy/#paste-filter-factory</a><br>
> ><br>
> > Ultimately, what you should want is to ask a factory method for a thing<br>
> > with some configuration options, and it spits an instance back at you.<br>
> > If your project doesn't support pastedeploy, that limits your options<br>
> > (ahem-ironic-ahem). Otherwise, it's really a team decision on whether<br>
> > something is a 'Fundamental feature' or something that's optional.<br>
> ><br>
> > In the case of Ceilometer? Sorry, but I think it's optional. You should<br>
> > be able to run any component of openstack without ceilometer. So I don't<br>
> > really think it should depend on oslo_config.<br>
><br>
> Ok, here is where I'm confused. Ceilometer middleware *already* depends<br>
> on oslo_config.<br>
><br>
> <a href="https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L42" rel="noreferrer" target="_blank">https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L42</a><br>
><br>
> And it does stuff with it here:<br>
><br>
> <a href="https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L107" rel="noreferrer" target="_blank">https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L107</a><br>
><br>
> But regardless, it uses oslo_messaging, which uses oslo_config. So it<br>
> seems like the only issue at hand is middleware retriggering conf parsing.<br>
><br>
> Because the current model of requiring simultaneous code lands in<br>
> oslo_messaging and ceilometermiddleware, and simultaneous config updates<br>
> in every installer and config management system to configure the same<br>
> thing in 2 different ways, does seem like a long term win. And honestly<br>
> just prohibits most of what people seem to want to do with new messaging<br>
> approaches.<br>
<br>
</div></div>I explained this on IRC, but I'll repeat it here as a more permanent<br>
record.<br>
<br>
We should not have the ceilometer middleware (re)initializing<br>
oslo.config. That combines 2 concerns (setting up configuration and<br>
doing whatever ceilometermiddleware is already doing) in one piece<br>
of middleware, and that will make it more difficult to combine<br>
ceilometermiddleware with other middleware that also wants access<br>
to the configuration settings.<br>
<br>
If the application code isn't setting up oslo.config, then we should<br>
have another piece of middleware do just that one thing. It can take<br>
options from paste's config to tell it how to do that work, and then<br>
other middleware later in the pipeline can rely on oslo.config being set<br>
up and the config files being loaded.<br>
<span class=""><font color="#888888"><br>
Doug<br>
</font></span><div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>Whatever is decided for this, I assume it'll also apply to the auth_token middleware, since that uses oslo.config, too. We already have a bug[1] and a proposed change[2] that isn't passing jenkins.<br><br>[1] <a href="https://bugs.launchpad.net/keystonemiddleware/+bug/1406218">https://bugs.launchpad.net/keystonemiddleware/+bug/1406218</a><br></div><div>[2] <a href="https://review.openstack.org/#/c/143063/">https://review.openstack.org/#/c/143063/</a><br></div><div><br></div><div>Brant<br><br></div></div></div></div>