Open Stack

On 1/29/14 7:39 PM, "Russell Bryant" <rbryant at redhat.com> wrote:

>On 01/29/2014 12:27 PM, Daniel P. Berrange wrote:
>> On Wed, Jan 29, 2014 at 11:47:07AM -0500, Russell Bryant wrote:
>>> Greetings,
>>>
>>> A while back I mentioned that we would revisit the potential
>>>deprecation
>>> of nova-network in Icehouse after the icehouse-2 milestone.  The time
>>> has come.  :-)
>>>
>>> First, let me recap my high level view of the blockers to deprecating
>>> nova-network in favor of Neutron:
>>>
>>>   - Feature parity
>>>     - The biggest gap here has been nova-network's multi-host mode.
>>>       Neutron needs some sort of HA for l3 agents, as well as the
>>>       ability to run in a mode that enables a single tenant's traffic
>>>       to be actively handled by multiple nodes.
>>>
>>>   - Testing / Quality parity
>>>     - Neutron needs to reach testing and quality parity in CI.  This
>>>       includes running the full tempest suite, for example.  For all
>>>       tests run against nova with nova-network that are applicable,
>>>they
>>>       need to be run against Neutron, as well.  All of these jobs
>>>should
>>>       have comparable or better reliability than the ones with
>>>       nova-network.
>>>
>>>   - Production-ready open source components
>>>     - nova-network provides basic, but usable in production networking
>>>       based purely on open source components.  Neutron must have
>>>       production-ready options based purely on open source components,
>>>       as well, that provides comparable or better performance and
>>>       reliability.
>> 
>> What, no mention of providing an automated upgrade path ? Given how
>> we go to great lengths to enable continuous deployment with automated
>> upgrade paths, I'd really expect to see something to deal with migrating
>> people from nova-network to neutron with existing tenants unaffected.

I was thinking for the upgrade process that we could leverage the port
attach/detach BP done by Dan Smith a while ago. This has libvirt support
and there are patches pending approval for Xen and Vmware. Not sure about
the other drivers.

If the guest can deal with the fact that the nova port is being removed
and a new logical port is added then we may have the chance of no down
time. If this works then we may need to add support for nova-network port
detach and we may have a seamless upgrade path.

>
>That's a good point.  This is actually a very sticky situation.  We have
>a upgrade path already, which is why I didn't mention it.  It's not
>really great though, so it's worth further discussion.  The path is
>roughly:
>
>1) Deploy a parallel nova install that uses Neutron, but shares all
>other services with the existing Nova that uses nova-network.
>(Keystone, glance, cinder, etc)
>
>2) Spawn new instances in the new Nova.
>
>3) For any instances that you want to migrate over to Neutron, snapshot
>them to glance, and then re-spawn them in the new Nova.
>
>This is the only plan that I've heard that we *know* should work for all
>deployment variations.  I've seen very little effort go into
>investigating or documenting any more advanced upgrade paths.
>
>The other upgrade piece is some sort of data migration.  There are some
>bits of data, such as security group definitions, that we should be able
>to automatically export from nova and import into neutron.  I don't
>think anyone has worked on that, either.
>
>-- 
>Russell Bryant
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
>bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
>H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=L%2FurKFNkdV1Uy8T0anh
>nW56lLyvFw%2BDQxjEDvp4Ji5I%3D%0A&s=27097272ad5841caccb4cf2ca0e9f6cf02cbf30
>a9cff5a58fcee92b9933bad37