<div dir="ltr">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.<div>

<br></div><div>First off, this upgrade was the easiest so far; great job! I only have a couple complaints to the community:</div><div><br></div><div>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.</div>

<div><br></div><div style>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).</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>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?</div>

<div style><br></div><div style>I'm using Ubuntu precise with the cloud archive. I also have some feedback there, and I'm hoping the packagers read this list...</div><div style><br></div><div style>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?</div>

<div style><br></div><div style>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).</div>

<div style><br></div><div style>- Ryan</div></div>