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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
