Open Stack

On Tue, Feb 4, 2014 at 8:19 AM, Sean Dague <sean at dague.net> wrote:
> On 02/05/2014 12:37 AM, Mark McLoughlin wrote:
>> On Mon, 2014-01-13 at 16:49 +0000, Sahid Ferdjaoui wrote:
>>> Hello all,
>>>
>>> It looks 100% of the pep8 gate for nova is failing because of a bug reported,
>>> we probably need to mark this as Critical.
>>>
>>>    https://bugs.launchpad.net/nova/+bug/1268614
>>>
>>> Ivan Melnikov has pushed a patchset waiting for review:
>>>    https://review.openstack.org/#/c/66346/
>>>
>>> http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==
>>
>> This just came up on #openstack-infra ...
>>
>> It's a general problem that is going to occur more frequently.
>>
>> Nova now includes config options from keystoneclient and oslo.messaging
>> in its sample config file.
>>
>> That means that as soon as a new option is added to either library, then
>> check_uptodate.sh will start failing.
>>
>> One option discussed is to remove the sample config files from source
>> control and have the sample be generated at build/packaging time.
>>
>> So long as we minimize the dependencies required to generate the sample
>> file, this should be manageable.
>
> The one big drawback here is that today you can point people to a git
> url, and they will then have a sample config file for Nova (or Tempest
> or whatever you are pointing them at). If this is removed, then we'll
> need / want some other way to make those samples easily available on the
> web, not only at release time.

+1, to the idea of removing this auto-generated file from the repo.

How about publishing these as part of the docs, we can put them in the
dev docs, so the nova options get published at:

http://docs.openstack.org/developer/nova/

etc, or we can make sure the main docs are always updated etc.

>
> On a related point, It's slightly bothered me that we're allow libraries
> to define stanzas in our config files. It seems like a leaky abstraction
> that's only going to get worse over time as we graduate more of oslo,
> and the coupling gets even worse.
>
> Has anyone considered if it's possible to stop doing that, and have the
> libraries only provide an object model that takes args and instead leave
> config declaration to the instantiation points for those objects?
> Because having a nova.conf file that's 30% options coming from
> underlying libraries that are not really controlable in nova seems like
> a recipe for a headache. We already have a bunch of that issue today
> with changing 3rd party logging libraries in oslo, that mostly means to
> do that in nova we first just go and change the incubator, then sync the
> changes back.
>
> I do realize this would be a rather substantial shift from current
> approach, but current approach seems to be hitting a new complexity
> point that we're only just starting to feel the pain on.
>
>         -Sean
>
> --
> Sean Dague
> Samsung Research America
> sean at dague.net / sean.dague at samsung.com
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>