Open Stack

On 05/28/2013 02:23 AM, Robert Collins wrote:
> So I find myself asking two questions:
> 
> a) why aren't the defaults suitable for production? Where they are not
> suitable, it's just friction waiting to trip new deployers up.
> 
> b) perhaps we can document - or even automate - some defaults for
> things like Quantum topology, which will work ok everywhere, and which
> we can tell folk who are just getting going 'follow this, it will work
> well enough for you to get experience with the rest of the system'.

Hi Robert,

It's amazing that you raise this topic when I just had many problems
with Quantum configuration. Thanks for raising it.

Indeed, I found the Quantum default configuration quite lacking (at
least in Grizzly, I haven't look into Havana yet), but also that this is
a general problem in OpenStack.

Everywhere in OpenStack, I have found that things which are commented
out are the default value. But that isn't always the case in Quantum. It
is very easy to fall into that trap, and stair hours at the
configuration files not understanding what is happening. This happened
to me. Therefore, my Quantum package is patching the default
configuration files (quantum.conf and the OVS ini file).

I also find it disturbing to read things like this in quantum.conf:

# Enable or disable pagination
# allow_pagination = False

I honestly have no idea what "pagination" is in the context of Quantum,
and I don't think anyone can pretend that the comment helps.

I also found it really disturbing that quantum.conf is missing a:
root_helper = sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf

in the [AGENT] section. Why isn't it like this by default?

While the rest of the people I work with (at eNovance) don't really care
about default config, since they use puppet anyway, I've been forcing
myself into using whatever I ship in my packages. And I am not
completely satisfied with it currently.

In Ceilometer and in Cinder, the <project>.conf.sample is simply
generated. While I like this approach (because nothing can be forgotten,
and that the default always are the correct ones that are in the code),
the final result is hard to parse by a human. Maybe a
<project>.conf.sample could be generated on all project by a script, and
a few configuration files made by humans could be packaged under
/usr/share/doc/<project>/example, so this way we would have best of both
world. For example:
/usr/share/doc/cinder/example/cinder-with-lvm-as-backend.conf.example
/usr/share/doc/cinder/example/cinder-with-ceph-as-backend.conf.example
/usr/share/doc/cinder/example/cinder-all-default-options.conf.sample

the first 2 would be human generated, with comments readable by humans,
while the last one would have been generated by the
./tools/conf/extract_opts.py script.

As you see above, I haven't been even talking about scalability, but
really about use cases, and sensible default here. As a package
maintainer, I think it is really important to have sensible defaults. A
part of my work has been to do exactly that for the Debian packages [1],
though I would much prefer to have these directly upstream. Your title
said it all, it has to work "out of the box", just after it's unpacked
by dpkg. And having possible examples in the doc folder would be a great
help too.

Just my 2 cents of feedback on the topic,

Thomas Goirand (zigo)

[1]
http://anonscm.debian.org/gitweb/?p=openstack/quantum.git;a=blob;f=debian/patches/better-default-config-values.patch