Open Stack

On Wed, 2014-02-05 at 01:19 +0900, Sean Dague 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.

I think that's best addressed by automatically publishing to somewhere
other than git.openstack.org. AFAIR there's already been a bunch of work
done around automatically pulling config options into the docs.

> 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

It is a little unusual, yes.

> that's only going to get worse over time as we graduate more of oslo,
> and the coupling gets even worse.

Worse in what respect?

> 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?

I think that would result in useless duplication (of those declarations)
and leave us open to projects having different config file options for
the same things.

> 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.

Why?

> 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.

That's a different issue - if we had a properly abstracted logging API,
we could commit to future API compat and publish an oslo.logging
library.

The syncing pain you describe would go away, and the proper abstraction
would mean the things that Nova needs to control would be under Nova's
control.

> 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.

The issue at hand is that we've discovered that checking an
autogenerated file into git causes issues ... hardly the first time
we've learned that lesson.

Mark.