<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 6:39 PM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Feb 4, 2014 at 8:19 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> 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>+1, to the idea of removing this auto-generated file from the repo.<br>
<br>
How about publishing these as part of the docs, we can put them in the<br>
dev docs, so the nova options get published at:<br>
<br>
<a href="http://docs.openstack.org/developer/nova/" target="_blank">http://docs.openstack.org/developer/nova/</a><br>
<br>
etc, or we can make sure the main docs are always updated etc.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I just talked with Anne, and she said the doc build now includes a Configuration Reference which is extracting the options and building nicely formatted tables. Given that, I don't think it adds much to include the config files as well.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Including the config file in either the developer documentation or the packaging build makes more sense. I'm still worried that adding it to the sdist generation means you would have to have a lot of tools installed just to make the sdist. However, we could include a script with each app that will generate the sample file for that app. Anyone installing from source could run it to build their own file, and the distro packagers could run it as part of their build and include the output in their package.</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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb"><br>
><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>
> that's only going to get worse over time as we graduate more of oslo,<br>
> and the coupling gets even worse.<br>
><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>
> 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. 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>
> 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>
> -Sean<br>
><br>
> --<br>
> Sean Dague<br>
> Samsung Research America<br>
> <a href="mailto:sean@dague.net">sean@dague.net</a> / <a href="mailto:sean.dague@samsung.com">sean.dague@samsung.com</a><br>
> <a href="http://dague.net" target="_blank">http://dague.net</a><br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
><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>