[openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond
mestery at siliconloons.com
Wed Jan 29 22:24:26 UTC 2014
On Jan 29, 2014, at 12:04 PM, Russell Bryant <rbryant at redhat.com> wrote:
> On 01/29/2014 12:45 PM, Daniel P. Berrange wrote:
>> I was thinking of an upgrade path more akin to what users got when we
>> removed the nova volume driver, in favour of cinder.
>> ie no guest visible downtime / interuption of service, nor running of
>> multiple Nova instances in parallel.
> Yeah, I'd love to see something like that. I would really like to see
> more effort in this area. I honestly haven't been thinking about it
> much in a while personally, because the rest of the "make it work" gaps
> have still been a work in progress.
> There's a bit of a bigger set of questions here, too ...
> Should nova-network *ever* go away? Or will there always just be a
> choice between the basic/legacy nova-network option, and the new fancy
> SDN-enabling Neutron option? Is the Neutron team's time better spent on
> OpenDaylight integration than the existing open source plugins?
This point about OpenDaylight vs. existing open source plugins is something
which some of us have talked about for a while now. I’ve spent a lot of time
with the OpenDaylight team over the last 2 months, and I believe once we
get that ML2 MechanismDriver upstreamed (waiting on third party testing and
reviews , perhaps we can at least remove some pressure agent-wise. The
current OpenDaylight driver doesn’t use a compute agent. And future iterations
will hopefully remove the need for an L3 agent as well, maybe even DHCP.
Since a lot of the gate issues seem to resolve around those things, my hope
is this approach can simplify some code and lead to more stability. But we’ll
see, we’re very early here at the moment.
> Depending on the answers to those questions, the non-visible no-downtime
> migration path may be a less important issue.
> Russell Bryant
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev