openstack team mailing list archive

[Narayan Desai <narayan.desai@xxxxxxxxx>]

On Thu, Jul 12, 2012 at 2:38 PM, Vishvananda Ishaya
<vishvananda@xxxxxxxxx> wrote:

> Agreed, I'm a developer, so I'm clearly biased towards what is easier for developers. It will be a significant effort to have to maintain the nova-volume code, so I want to be sure it is necessary. End users really shouldn't care about this, so the other community members who are impacted are operators.
>
> I really would like more feedback on how painful it will be for operators if we force them to migrate. We have one clear response from Chuck, which is very helpful. Is there anyone else out there running nova-volume that would prefer to keep it when they move to folsom?

I think that the long term maintenance or removal of nova-volume in
its existing form is orthogonal to the actual issue of continuity from
one release to the next.

At this point, we've now run cactus, diablo and are in testing with
essex. Each of these has effectively been a flag day for us; we build
the new system, migrate users, images, etc, and let users do a bunch
of manual migration of volume data, etc, while running both systems in
parallel. This hasn't been as painful as it sounds because our
understanding of best practices for running openstack is moving pretty
quickly and each system has been quite different from the previous.

The lack of an effective process to move from one major release to the
next is the major issue here in my mind. It would be fantastic if
(some day, ha ha ha) you could apt-get upgrade from folsom to grizzly,
but i think that is likely to be more trouble than it is worth. A
reasonable compromise would be a well documented process as well as
tools to aid in the process. Each real deployment will have a
substantial set of local customizations, particularly if they are
running at any sort of scale. While it won't be feasible to support
any upgrade with these customizations, tools for the process (which
may only be used a straw man in complex cases) would go a long way.
 -nld