<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 11:36 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Wed, 2014-02-05 at 01:19 +0900, Sean Dague wrote:<br>

> On 02/05/2014 12:37 AM, Mark McLoughlin wrote:<br>
> > On Mon, 2014-01-13 at 16:49 +0000, Sahid Ferdjaoui wrote:<br>
> >> Hello all,<br>
> >><br>
> >> It looks 100% of the pep8 gate for nova is failing because of a bug reported,<br>
> >> we probably need to mark this as Critical.<br>
> >><br>
> >>    <a href="https://bugs.launchpad.net/nova/+bug/1268614" target="_blank">https://bugs.launchpad.net/nova/+bug/1268614</a><br>
> >><br>
> >> Ivan Melnikov has pushed a patchset waiting for review:<br>
> >>    <a href="https://review.openstack.org/#/c/66346/" target="_blank">https://review.openstack.org/#/c/66346/</a><br>
> >><br>
> >> <a href="http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==" target="_blank">http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==</a><br>

> ><br>
> > This just came up on #openstack-infra ...<br>
> ><br>
> > It's a general problem that is going to occur more frequently.<br>
> ><br>
> > Nova now includes config options from keystoneclient and oslo.messaging<br>
> > in its sample config file.<br>
> ><br>
> > That means that as soon as a new option is added to either library, then<br>
> > check_uptodate.sh will start failing.<br>
> ><br>
> > One option discussed is to remove the sample config files from source<br>
> > control and have the sample be generated at build/packaging time.<br>
> ><br>
> > So long as we minimize the dependencies required to generate the sample<br>
> > file, this should be manageable.<br>
><br>
> The one big drawback here is that today you can point people to a git<br>
> url, and they will then have a sample config file for Nova (or Tempest<br>
> or whatever you are pointing them at). If this is removed, then we'll<br>
> need / want some other way to make those samples easily available on the<br>
> web, not only at release time.<br>
<br>
</div></div>I think that's best addressed by automatically publishing to somewhere<br>
other than <a href="http://git.openstack.org" target="_blank">git.openstack.org</a>. AFAIR there's already been a bunch of work<br>
done around automatically pulling config options into the docs.<br>
<div class="im"><br>
> On a related point, It's slightly bothered me that we're allow libraries<br>
> to define stanzas in our config files. It seems like a leaky abstraction<br>
<br>
</div>It is a little unusual, yes.<br>
<div class="im"><br>
> that's only going to get worse over time as we graduate more of oslo,<br>
> and the coupling gets even worse.<br>
<br>
</div>Worse in what respect?<br>
<div class="im"><br>
> Has anyone considered if it's possible to stop doing that, and have the<br>
> libraries only provide an object model that takes args and instead leave<br>
> config declaration to the instantiation points for those objects?<br>
<br>
</div>I think that would result in useless duplication (of those declarations)<br>
and leave us open to projects having different config file options for<br>
the same things.<br>
<div class="im"><br>
> Because having a nova.conf file that's 30% options coming from<br>
> underlying libraries that are not really controlable in nova seems like<br>
> a recipe for a headache.<br>
<br>
</div>Why?<br>
<div class="im"><br>
> We already have a bunch of that issue today<br>
> with changing 3rd party logging libraries in oslo, that mostly means to<br>
> do that in nova we first just go and change the incubator, then sync the<br>
> changes back.<br>
<br>
</div>That's a different issue - if we had a properly abstracted logging API,<br>
we could commit to future API compat and publish an oslo.logging<br>
library.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Roman's patch to make the ContextFormatter do most of the work [1] instead of having adapters is the first step to making oslo.logging be a library for configuring logging so that apps and libraries can use python's stdlib logging module to actually get the logger objects. </div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[1] <a href="https://review.openstack.org/#/c/63782/">https://review.openstack.org/#/c/63782/</a></div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
The syncing pain you describe would go away, and the proper abstraction<br>
would mean the things that Nova needs to control would be under Nova's<br>
control.<br>
<div class="im"><br>
> I do realize this would be a rather substantial shift from current<br>
> approach, but current approach seems to be hitting a new complexity<br>
> point that we're only just starting to feel the pain on.<br>
<br>
</div>The issue at hand is that we've discovered that checking an<br>
autogenerated file into git causes issues ... hardly the first time<br>
we've learned that lesson.<br>
<div class=""><div class="h5"><br>
Mark.<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>