openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #14582
Re: Release Upgrades (was [nova] [cinder] Nova-volume vs. Cinder in Folsom)
On Thu, Jul 12, 2012 at 4:36 PM, Vishvananda Ishaya
<vishvananda@xxxxxxxxx> wrote:
> Upgrading has been painful and we are striving to improve this process
> as much as possible.
I think that this needs to be a core value of the developer community,
if Openstack is going to become pervasive.
> I would like to take this a bit further. Documentation is a great first step,
> but I would actually like to have an actual Jenkins test that does the upgrade
> from essex to Folsom with live resources created. I think this the only way
> that we can be sure that the upgrade is working properly.
I don't want to dampen enthusiasm around this issue at all, but I
think this goal is pretty difficult to achieve, just due to the
existing complexity in real deployments. I'm also worried that this
would take away from a high level upgrade documentation goal.
>
> The first version of this doesn't even have to be on a full cluster. I'm thinking
> something as simple as:
>
> * configure devstack to checkout stable/essex from all of the projects
> * run the system, launch some instances and volumes
> * terminate the workers
> * upgrade all of the code to folsom
> * do any manual upgrade steps (nova-manage db sync, cinder migrate, etc.)
> * run all the workers
> * make sure the existing data still works and new api commands run
>
> The manual upgrade steps should be contained in a single script so that the
> distress can use it to help make their package upgrades and deployers can
> use it for reference when upgrading their clusters.
>
> This is something we can start working on today and we can run after each
> commit. Then we will immediately know if we do something that breaks
> upgradability, and we will have a testable documented process for upgrading.
Having a testable process for upgrading is definitely a start. I guess
that I am more or less resigned to upgrades being pretty effort
intensive, at least in the near term, so my personal bias is towards
getting pretty extreme documentation done first.
-nld
References