[openstack-dev] Upgraded from essex -> folsom; some feedback
Ryan Lane
rlane at wikimedia.org
Wed May 15 22:54:51 UTC 2013
I've just upgraded my production nova/glance/keystone infrastructure from
essex to folsom and I'd like to provide some feedback. I know I'm a full
release behind, but I don't feel like I'm out of the ordinary for this as a
production user.
First off, this upgrade was the easiest so far; great job! I only have a
couple complaints to the community:
1. The documentation for upgrading was basically non-existent. There was a
small amount of information in the release notes regarding upgrading, and
they were helpful, but upgrade documentation they are not. It looks like
this is still the case with the grizzly release.
There's no documentation on which configuration options were added (and are
required) or removed. There's none about new configuration files that are
used. There's none about the changes to the policy.conf files (which is
really evil, because that has security concerns).
I'm fairly familiar with the code base and very familiar with the services,
so I was able to create upgraded configuration files somewhat easily, but a
less experienced user would likely have had a much harder time with this.
2. Having configuration in the paste files *really* sucks. The vast
majority of that simply isn't configuration. Since those files are in /etc,
packages will treat them as configuration files, and the default for
packages is to not replace configuration files (especially when using
puppet/salt/etc). That means the paste files will be completely wrong after
an upgrade. Can the configuration be split away from the paste files?
I'm using Ubuntu precise with the cloud archive. I also have some feedback
there, and I'm hoping the packagers read this list...
glance-registry, on install, initializes the sqlite database. If you purge
the package then reinstall, the installation fails because the database is
already initialized. Why not leave that step to the user?
Also, when doing an upgrade, package upgrades cause a service start. With
the current upgrade process that's definitely non-ideal. I know it's
possible to disable this per-package, but it would be nice if it was
disabled by default for upgrading between major versions (until live
upgrades are supported by OpenStack).
- Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130515/a1e21c58/attachment.html>
More information about the OpenStack-dev
mailing list