Open Stack

>
> Migrations from Essex to Grizzly/Havana

...

I would find it entirely suitable to upgrade from Essex to Folsom, then
> migrate from nova-volume to cinder and from nova-network to quantum, then
> only to upgrade to Grizzly.


We're in the same spot, upgrading an Essex deployment to Havana. We decided
to forego an incremental upgrade of nova, glance and keystone since it was
not clear that we could perform that upgrade without a major service
disruption to active VMs. Additionally we had no good way of fully testing
the upgrade beforehand.

However, we have a nova-volume service hosting ~ 500TB of volume data (>
200 volumes) using the ZFS driver. We'd like to be able to "carry" these
volumes over the upgrade to cinder. Our current strategy is to deploy
cinder and nova-volume on the same machine with separate ZFS pools. When a
user's ready to upgrade a volume, they hit a button; a script fires off 1)
creating a new cinder volume, 2) rename the nova-volume in ZFS to the new
cinder one and 3) deleting the old nova-volume record.

That's the plan, at least.

~ Scott


On Fri, Nov 1, 2013 at 3:16 PM, Dean Troyer <dtroyer at gmail.com> wrote:

> On Fri, Nov 1, 2013 at 1:38 PM, Devananda van der Veen <
> devananda.vdv at gmail.com> wrote:
>
>> Actually, anyone deploying nova with the "baremetal" driver will face a
>> similar split when Ironic is included in the release. I'm targeting
>> Icehouse, but of course, it's up to the TC when Ironic graduates.
>>
>> This should have a smaller impact than either the neutron or cinder
>> splits, both of which were in widespread use, but I expect we'll see more
>> usage of nova-baremetal crop up now that Havana is released.
>>
>
> I didn't recall in which release baremetal was first a supported option,
> is it only now in Havana?  Is it clear in the docs that this sort of
> situation is coming in the next release or two? (And no, I haven't gone to
> look for myself, maybe on the plane tomorrow...)
>
> dt
>
> --
>
> Dean Troyer
> dtroyer at gmail.com
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131102/7ac6437f/attachment.html>