Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Matt Riedemann]

On 1/30/2014 7:10 AM, Christopher Yeoh wrote:

On Thu, Jan 30, 2014 at 2:08 PM, Michael Still mailto:mi...@stillhq.com>> wrote:

On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh mailto:cbky...@gmail.com>> wrote:

 > So if nova-network doesn't go away this has implications for the
V3 API as
 > it currently doesn't support
 > nova-network. I'm not sure that we have time to add support for it in
 > icehouse now, but if nova-network is
 > not going to go away then we need to add it to the V3 API or we
will be
 > unable to ever deprecate the
 > V2 API.

Is the problem here getting the code written, or getting it through
reviews? i.e. How can I re-prioritise work to help you here?


So I think its a combination of both. There's probably around 10
extensions from V2 that would need looking at to port from V2. There's
some cases where the API supported both nova network and neutron,
proxying in the latter case and others where only nova network was
supported. So we'll need to make a decision pretty quickly around
whether we present a unified networking interface (eg proxy for neutron)
or have some interfaces which you only use when you use nova-network.
There's a bit of work either way. Also given how long we'll have V3 for
want to take the opportunity to cleanup the APIs we do port. And feature
proposal deadline is now less than 3 weeks away so combined with the
already existing work we have for i-3 it is going to be a little tight.

The other issue is we have probably at least 50 or so V3 API related
changesets in the queue at the moment, plus obviously more coming over
the next few weeks. So I'm a bit a wary of how much extra review
attention we can realistically expect.

The two problems together make me think that although its not
impossible, there's a reasonable level of risk that we wouldn't get it
all done AND merged in i-3. And I think we want to avoid the situation
where we have some of the things currently in the queue merged and some
of say the nova-network patches done, but not complete with either. More
people contributing patches and core review cycles will of course help
though so any help is welcome :-)

This is all dependent on nova-network never going away. If the intent is
that it would eventually be deprecated - say in the same timeframe as
the V2 API then I don't think its worth the extra effort/risk putting it
in the V3 API in icehouse.

Regards,

Chris


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Given the above, I'm trying to figure out if the limits/used_limits API 
extensions will come back in nova V3?  I ask because I'm trying to get 
this patch [1] working for V2 and earlier in the review cycle it was 
asserted it could be a V2-only change since Neutron would be handled 
differently in V3, but now I'm confused.


[1] https://review.openstack.org/#/c/43822/

--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Christopher Yeoh]

On Fri, Jan 31, 2014 at 3:21 AM, Dan Smith  wrote:

> > If necessary the tasks work could be done solely as an extension, but I
> > would really prefer to avoid that so I'll get this ball rolling quickly.
>
> I agree that doing it as a bolt-on to v3 would be significantly less
> favorable than making it an integrated feature of the API. IMHO, if a
> server create operation doesn't return a task, then we failed, as that
> is (to me) one of the primary cases where a task object is important.
>
>
So the server create operation currently has a flag to say whether to
return a bunch of information
about the server being created (although we don't yet know if it will
succeed), OR return
a reservation_id which can then be used as a filter for getting information
about a server.

If we made this reservation_id just happen to be the same as the task id
handle returned then I think this
would be a pretty clean change (I don't know how this fits into the current
design?). The existing
reservation_id is a bit tasky-looking already.

Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Dan Smith]

> If necessary the tasks work could be done solely as an extension, but I
> would really prefer to avoid that so I'll get this ball rolling quickly.

I agree that doing it as a bolt-on to v3 would be significantly less
favorable than making it an integrated feature of the API. IMHO, if a
server create operation doesn't return a task, then we failed, as that
is (to me) one of the primary cases where a task object is important.

--Dan


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Andrew Laski]

On 01/30/14 at 09:31am, Russell Bryant wrote:

On 01/30/2014 09:13 AM, Christopher Yeoh wrote:


On Fri, Jan 31, 2014 at 12:27 AM, Russell Bryant 

Well, it depends.

If the tasks API is going to purely be an add-on, then sure, I agree.
If it's a fundamental shift to the existing API, including changing how
we respond to things like creating a server, then I think it has to wait.

We really need to have some rough design agreed upon to make this call
effectively.  In the absence of that, I think the right thing to do is
to proceed with v3 as it stands, which will put some limitations on how
drastic the tasks addition can be.


I just recently had a chance to put some serious effort into this and 
should have something together for discussion and design soon.  It's 
unfortunate that it's happening this late though.


Based on what I've done so far, the main change from what the APIs are 
doing now is a new Location header and a task object in the response for 
POST requests.  For a server create this is a bigger change than server 
actions because the task would replace the server in the response.


If necessary the tasks work could be done solely as an extension, but I 
would really prefer to avoid that so I'll get this ball rolling quickly.




--
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Russell Bryant]

On 01/30/2014 09:13 AM, Christopher Yeoh wrote:
> 
> On Fri, Jan 31, 2014 at 12:27 AM, Russell Bryant  I can't say in any sort of confidence that I think nova-network will go
> away in the foreseeable future.  Yes, this has an unfortunate big impact
> on our original plan for the v3 API.  :-(
> 
> However, I'm also not sure about the status of v3 in Icehouse, anyway.
> One of the key things I want to see in before we freeze the API is the
> tasks work.  AFAIK, there hasn't been any design review on this, much
> less code review.  It seems incredibly unlikely that it will be done for
> Icehouse at this point.  Andrew, thoughts?
> 
> 
> I don't think the lack the tasks api being merged should stop us from
> releasing the V3 API (it perhaps means there is one less significant
> reason for people to move from the V2 API). Releasing the v3 API doesn't
> stop us from adding tasks at a later stage to the V3 API as it could be
> a simple additional way to interact and in practice I'd imagine there
> will be gradual increase in support of doing things in a tasks oriented
> way rather than a big bang everything now uses tasks approach.
> 
> And the sooner we can release the V3 API, the sooner we can put the V2
> API into maintenance mode and avoid the overhead of having every new
> feature having to be written for both.

Well, it depends.

If the tasks API is going to purely be an add-on, then sure, I agree.
If it's a fundamental shift to the existing API, including changing how
we respond to things like creating a server, then I think it has to wait.

We really need to have some rough design agreed upon to make this call
effectively.  In the absence of that, I think the right thing to do is
to proceed with v3 as it stands, which will put some limitations on how
drastic the tasks addition can be.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Christopher Yeoh]

On Fri, Jan 31, 2014 at 12:27 AM, Russell Bryant  wrote:

> On 01/30/2014 08:10 AM, Christopher Yeoh wrote:
> > On Thu, Jan 30, 2014 at 2:08 PM, Michael Still  > > wrote:
> >
> > On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh  > > wrote:
> >
> > > So if nova-network doesn't go away this has implications for the
> > V3 API as
> > > it currently doesn't support
> > > nova-network. I'm not sure that we have time to add support for it
> in
> > > icehouse now, but if nova-network is
> > > not going to go away then we need to add it to the V3 API or we
> > will be
> > > unable to ever deprecate the
> > > V2 API.
> >
> > Is the problem here getting the code written, or getting it through
> > reviews? i.e. How can I re-prioritise work to help you here?
> >
> >
> > So I think its a combination of both. There's probably around 10
> > extensions from V2 that would need looking at to port from V2. There's
> > some cases where the API supported both nova network and neutron,
> > proxying in the latter case and others where only nova network was
> > supported. So we'll need to make a decision pretty quickly around
> > whether we present a unified networking interface (eg proxy for neutron)
> > or have some interfaces which you only use when you use nova-network.
> > There's a bit of work either way. Also given how long we'll have V3 for
> > want to take the opportunity to cleanup the APIs we do port. And feature
> > proposal deadline is now less than 3 weeks away so combined with the
> > already existing work we have for i-3 it is going to be a little tight.
> >
> > The other issue is we have probably at least 50 or so V3 API related
> > changesets in the queue at the moment, plus obviously more coming over
> > the next few weeks. So I'm a bit a wary of how much extra review
> > attention we can realistically expect.
> >
> > The two problems together make me think that although its not
> > impossible, there's a reasonable level of risk that we wouldn't get it
> > all done AND merged in i-3. And I think we want to avoid the situation
> > where we have some of the things currently in the queue merged and some
> > of say the nova-network patches done, but not complete with either. More
> > people contributing patches and core review cycles will of course help
> > though so any help is welcome :-)
> >
> > This is all dependent on nova-network never going away. If the intent is
> > that it would eventually be deprecated - say in the same timeframe as
> > the V2 API then I don't think its worth the extra effort/risk putting it
> > in the V3 API in icehouse.
>
> I can't say in any sort of confidence that I think nova-network will go
> away in the foreseeable future.  Yes, this has an unfortunate big impact
> on our original plan for the v3 API.  :-(
>
> However, I'm also not sure about the status of v3 in Icehouse, anyway.
> One of the key things I want to see in before we freeze the API is the
> tasks work.  AFAIK, there hasn't been any design review on this, much
> less code review.  It seems incredibly unlikely that it will be done for
> Icehouse at this point.  Andrew, thoughts?
>
>
I don't think the lack the tasks api being merged should stop us from
releasing the V3 API (it perhaps means there is one less significant reason
for people to move from the V2 API). Releasing the v3 API doesn't stop us
from adding tasks at a later stage to the V3 API as it could be a simple
additional way to interact and in practice I'd imagine there will be
gradual increase in support of doing things in a tasks oriented way rather
than a big bang everything now uses tasks approach.

And the sooner we can release the V3 API, the sooner we can put the V2 API
into maintenance mode and avoid the overhead of having every new feature
having to be written for both.

Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Russell Bryant]

On 01/29/2014 05:24 PM, Kyle Mestery wrote:
> 
> On Jan 29, 2014, at 12:04 PM, Russell Bryant  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.
>>>
>>>  https://wiki.openstack.org/wiki/MigrateToCinder
>>>
>>> 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 [1], 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.

I think this point is really important and I'd love to see more input
from others on the Neutron side.

There's the long term view: where are we headed?  What's the
nova-network/Nova+neutron end game?

There's also the short term issues: Neutron reliability has been causing
massive pain in the OpenStack gate for months.  Are we going through
this pain for no good reason if we expect these plugins to go away
before becoming a viable production option?

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Russell Bryant]

On 01/30/2014 08:10 AM, Christopher Yeoh wrote:
> On Thu, Jan 30, 2014 at 2:08 PM, Michael Still  > wrote:
> 
> On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh  > wrote:
> 
> > So if nova-network doesn't go away this has implications for the
> V3 API as
> > it currently doesn't support
> > nova-network. I'm not sure that we have time to add support for it in
> > icehouse now, but if nova-network is
> > not going to go away then we need to add it to the V3 API or we
> will be
> > unable to ever deprecate the
> > V2 API.
> 
> Is the problem here getting the code written, or getting it through
> reviews? i.e. How can I re-prioritise work to help you here?
> 
> 
> So I think its a combination of both. There's probably around 10
> extensions from V2 that would need looking at to port from V2. There's
> some cases where the API supported both nova network and neutron,
> proxying in the latter case and others where only nova network was
> supported. So we'll need to make a decision pretty quickly around
> whether we present a unified networking interface (eg proxy for neutron)
> or have some interfaces which you only use when you use nova-network.
> There's a bit of work either way. Also given how long we'll have V3 for
> want to take the opportunity to cleanup the APIs we do port. And feature
> proposal deadline is now less than 3 weeks away so combined with the
> already existing work we have for i-3 it is going to be a little tight.
> 
> The other issue is we have probably at least 50 or so V3 API related
> changesets in the queue at the moment, plus obviously more coming over
> the next few weeks. So I'm a bit a wary of how much extra review
> attention we can realistically expect.
> 
> The two problems together make me think that although its not
> impossible, there's a reasonable level of risk that we wouldn't get it
> all done AND merged in i-3. And I think we want to avoid the situation
> where we have some of the things currently in the queue merged and some
> of say the nova-network patches done, but not complete with either. More
> people contributing patches and core review cycles will of course help
> though so any help is welcome :-)
> 
> This is all dependent on nova-network never going away. If the intent is
> that it would eventually be deprecated - say in the same timeframe as
> the V2 API then I don't think its worth the extra effort/risk putting it
> in the V3 API in icehouse.

I can't say in any sort of confidence that I think nova-network will go
away in the foreseeable future.  Yes, this has an unfortunate big impact
on our original plan for the v3 API.  :-(

However, I'm also not sure about the status of v3 in Icehouse, anyway.
One of the key things I want to see in before we freeze the API is the
tasks work.  AFAIK, there hasn't been any design review on this, much
less code review.  It seems incredibly unlikely that it will be done for
Icehouse at this point.  Andrew, thoughts?

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Christopher Yeoh]

On Thu, Jan 30, 2014 at 2:08 PM, Michael Still  wrote:

> On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh 
> wrote:
>
> > So if nova-network doesn't go away this has implications for the V3 API
> as
> > it currently doesn't support
> > nova-network. I'm not sure that we have time to add support for it in
> > icehouse now, but if nova-network is
> > not going to go away then we need to add it to the V3 API or we will be
> > unable to ever deprecate the
> > V2 API.
>
> Is the problem here getting the code written, or getting it through
> reviews? i.e. How can I re-prioritise work to help you here?
>
>
So I think its a combination of both. There's probably around 10 extensions
from V2 that would need looking at to port from V2. There's some cases
where the API supported both nova network and neutron, proxying in the
latter case and others where only nova network was supported. So we'll need
to make a decision pretty quickly around whether we present a unified
networking interface (eg proxy for neutron) or have some interfaces which
you only use when you use nova-network. There's a bit of work either way.
Also given how long we'll have V3 for want to take the opportunity to
cleanup the APIs we do port. And feature proposal deadline is now less than
3 weeks away so combined with the already existing work we have for i-3 it
is going to be a little tight.

The other issue is we have probably at least 50 or so V3 API related
changesets in the queue at the moment, plus obviously more coming over the
next few weeks. So I'm a bit a wary of how much extra review attention we
can realistically expect.

The two problems together make me think that although its not impossible,
there's a reasonable level of risk that we wouldn't get it all done AND
merged in i-3. And I think we want to avoid the situation where we have
some of the things currently in the queue merged and some of say the
nova-network patches done, but not complete with either. More people
contributing patches and core review cycles will of course help though so
any help is welcome :-)

This is all dependent on nova-network never going away. If the intent is
that it would eventually be deprecated - say in the same timeframe as the
V2 API then I don't think its worth the extra effort/risk putting it in the
V3 API in icehouse.

Regards,

Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Jesse Pretorius]

Applicable Blueprints:
https://blueprints.launchpad.net/neutron/+spec/nova-to-quantum-upgrade
https://blueprints.launchpad.net/nova/+spec/deprecate-nova-network
https://blueprints.launchpad.net/neutron/+spec/nova-network-to-neutron-recipes

Previous Discussions that relate:
http://www.gossamer-threads.com/lists/openstack/dev/18373
http://www.gossamer-threads.com/lists/openstack/operators/31312
http://www.gossamer-threads.com/lists/openstack/operators/22837
http://www.gossamer-threads.com/lists/openstack/dev/30102
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Jesse Pretorius]

>
> Tasks which we've identified need to be done:
>
> 1) Convert existing networks
> 2) Convert existing port allocations
> 3) Convert existing security groups
> 4) Convert existing security rules
> 5) Convert existing floating IP allocations
>

Additional tasks:

6) Create routers for each network, where applicable
7) Set the gateway for the routers
8) Create internal interfaces for the routers on the instance subnets
9) Convert the nova-network DNS server entries to DNS entries for the
Neutron Subnets, or set some default DNS entries for those that don't have
any. Perhaps there should also be an option to override any existing DNS
entries with the defaults.

 The conversion approach could either be to directly manipulate the
database tables or to use the API's. My thinking is that using the API's
for the Neutron activities would be better as it would provide better
backwards/forwards compatibility, whereas directly accessing the database
for the source data will be a suitable approach. Thoughts?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Jesse Pretorius]

On 29 January 2014 23:13, Vishvananda Ishaya  wrote:

>  I see the process as going something like this:
>
> * Migrate network data from nova into neutron
> * Turn off nova-network on the node
> * Run the neutron l3 agent and trigger it to create the required bridges
> etc.
> * Use ovsctl to remove the vnic from the nova bridge and add it to the
> appropriate ovs bridge
>
> Because the ovs bridge and the nova bridge are plugged in to the same
> physical
> device, traffic flows appropriately.
>
> There is some hand waving above about how to trigger the l3 agent to
> create the
> ports and security groups properly, but I think conceptually it could work.
>

This is a task on my list to achieve in the next few months. The
non-trivial aspect is step one as you've described it here. I would really
appreciate it if a collaboration of those who know the nova-network data
and those who know the neutron data could be put together in order to write
some tooling to convert the network data.

Tasks which we've identified need to be done:

1) Convert existing networks
In our scenario we're using nova-network with VLANManager. Our target is a
Neutron setup with name spaces, GRE tunnels and OpenVSwitch. In some cases
networks need to be converted to provider networks to maintain
functionality, in other cases the networks can be converted to completely
virtual networks. The options here would point to the conversion requiring
some sort of selection for the network to convert in a particular way. The
selection being a single network or a set of networks.
A reasonable simple start would simply be to convert all networks the same
way.

2) Convert existing port allocations
When switching from nova-network to neutron the instance NIC's end up
losing their port allocations. These have to be added, connecting them with
the same IP address to the same instance on the same network (after it's
converted). A specific requirement here is that the port assigned to the
instance must have the same MAC address as it had before, otherwise Windows
will require re-activation and linux will see the new port as an
alternative network device and add it as the next NIC instead of using the
same NIC that it already has.

3) Convert existing security groups
4) Convert existing security rules
5) Convert existing floating IP allocations

On 30 January 2014 08:14, Joshua Harlow  wrote:

> 1. Take offline APIs & nova-compute (so new/existing VMs can't be
> scheduled/modified) -- existing running VMs will not be affected.
> 2. Save/dump nova database.
> 3. Translate nova database entries into corresponding neutron database
> entries.
> 4. Remove/adjust the *right* entries of the nova database.
> 5. Startup neutron+agents with database that it believes it was running
> with the whole time.
> 6. Restart nova-api & nova-compute (it will now never know that it was
> previously using nova-network).
> 7. Profit!


In our view, taking the API's and nova-compute off-line for the conversion
period is perfectly acceptable. This is, after all, a major plumbing change
in the architecture!

If we can't do this with all instances remaining online for most of the
line (there will have to be a slight disruption as the traffic flows change
to go through the L3 Agent), then ideally we should be able to convert a
single node at a time so that we can manage the disruption with our
customers.

My challenge is that I'm more of an operator than a developer. My python
skills would rate as 'noob' or perhaps at most 'bugfixer'. Ideally I need
the skills of a learned group with the same itch to scratch to work with to
make this happen. If such a Holy Grail is not found, I shall find a way but
it won't be pretty. ;)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Joshua Harlow]

I think depending on use-case it can be accomplished.

The steps we have been thinking at Y!

1. Take offline APIs & nova-compute (so new/existing VMs can't be
scheduled/modified) -- existing running VMs will not be affected.
2. Save/dump nova database.
3. Translate nova database entries into corresponding neutron database
entries.
4. Remove/adjust the *right* entries of the nova database.
5. Startup neutron+agents with database that it believes it was running
with the whole time.
6. Restart nova-api & nova-compute (it will now never know that it was
previously using nova-network).
7. Profit!

Depending on the use-case and how complex your impl. is something like the
above should work. Of course the devil is in the details ;)

On 1/29/14, 11:50 AM, "Tim Bell"  wrote:

>
>I'm not seeing a path to migrate 1,000s of production VMs from nova
>network to Neutron.
>
>Can someone describe how this can be done without downtime for the VMs ?
>
>Can we build an approach for the cases below in a single OpenStack
>production cloud:
>
>1. Existing VMs to carry on running without downtime (and no new features)
>2. Existing VMs to choose a window for reconfiguration for Neutron (to
>get the new function)
>3. New VMs to take advantage of Neutron features such as LBaaS
>- 
>Tim
>
>> -Original Message-
>> From: Russell Bryant [mailto:rbry...@redhat.com]
>> Sent: 29 January 2014 19:04
>> To: Daniel P. Berrange
>> Cc: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse
>>and beyond
>> 
>> 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.
>> >
>> >   https://wiki.openstack.org/wiki/MigrateToCinder
>> >
>> > 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?
>> 
>> 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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Michael Still]

On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh  wrote:

> So if nova-network doesn't go away this has implications for the V3 API as
> it currently doesn't support
> nova-network. I'm not sure that we have time to add support for it in
> icehouse now, but if nova-network is
> not going to go away then we need to add it to the V3 API or we will be
> unable to ever deprecate the
> V2 API.

Is the problem here getting the code written, or getting it through
reviews? i.e. How can I re-prioritise work to help you here?

Michael

-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Christopher Yeoh]

On Thu, Jan 30, 2014 at 4:34 AM, Russell Bryant  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.
> >
> >   https://wiki.openstack.org/wiki/MigrateToCinder
> >
> > 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?
>
>
So if nova-network doesn't go away this has implications for the V3 API as
it currently doesn't support
nova-network. I'm not sure that we have time to add support for it in
icehouse now, but if nova-network is
not going to go away then we need to add it to the V3 API or we will be
unable to ever deprecate the
V2 API.

Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Kyle Mestery]

On Jan 29, 2014, at 12:04 PM, Russell Bryant  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.
>> 
>>  https://wiki.openstack.org/wiki/MigrateToCinder
>> 
>> 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 [1], 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.

Thanks,
Kyle

[1] https://review.openstack.org/#/c/69775/1

> 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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Russell Bryant]

On 01/29/2014 04:20 PM, Kashyap Chamarthy wrote:
> On 01/29/2014 11:34 PM, Russell Bryant wrote:
> 
> [. . .]
> 
>> 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?
> 
> I'll keep in mind you called these as 'bigger set of questions', that
> said -- I hope your above question will not be misinterpreted as in open
> source plugins can be treated as second-class citizens.
> 
> 
> If I'm saying something silly, don't hesitate to call me out.

Note that the alternative I mentioned is another open source thing.

Neutron must have a production viable, completely open source option to
ever be considered a replacement for anything, IMO, as noted in my first
message in this thread..

>>
>> 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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Kashyap Chamarthy]

On 01/29/2014 11:34 PM, Russell Bryant wrote:

[. . .]

> 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?

I'll keep in mind you called these as 'bigger set of questions', that
said -- I hope your above question will not be misinterpreted as in open
source plugins can be treated as second-class citizens.


If I'm saying something silly, don't hesitate to call me out.

> 
> Depending on the answers to those questions, the non-visible no-downtime
> migration path may be a less important issue.
> 


-- 
/kashyap

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Vishvananda Ishaya]

On Jan 29, 2014, at 10:45 AM, Dan Smith  wrote:

>> 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 thought for sure. However, it would be much better if we
> could avoid literally detaching the VIF from the guest and instead just
> swap where the other end is plugged into. With virtual infrastructure,
> that should be pretty easy to do, unless you're switching actual L2
> networks. If you're doing the latter, however, you might as well reboot
> the guest I think.
> 
> —Dan

I did a very brief investigation into this about six months ago moving
nova-network over to l3-agent using ovs. I think it should be possible, but
I got a little bit stuck on a technical point and then got involved with
other things. I see the process as going something like this:

* Migrate network data from nova into neutron
* Turn off nova-network on the node
* Run the neutron l3 agent and trigger it to create the required bridges etc.
* Use ovsctl to remove the vnic from the nova bridge and add it to the 
appropriate ovs bridge

Because the ovs bridge and the nova bridge are plugged in to the same physical
device, traffic flows appropriately.

There is some hand waving above about how to trigger the l3 agent to create the
ports and security groups properly, but I think conceptually it could work.

I tried to do the above via devstack but it isn’t quite trivial to get devstack
to install and run neutron without deleting everything and starting over. Even
this doesn’t seem particularly hard, I just ran out of time to focus on it.

Vish
 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Tim Bell]

I'm not seeing a path to migrate 1,000s of production VMs from nova network to 
Neutron.

Can someone describe how this can be done without downtime for the VMs ?

Can we build an approach for the cases below in a single OpenStack production 
cloud:

1. Existing VMs to carry on running without downtime (and no new features)
2. Existing VMs to choose a window for reconfiguration for Neutron (to get the 
new function)
3. New VMs to take advantage of Neutron features such as LBaaS
- 
Tim

> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: 29 January 2014 19:04
> To: Daniel P. Berrange
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and 
> beyond
> 
> 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.
> >
> >   https://wiki.openstack.org/wiki/MigrateToCinder
> >
> > 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?
> 
> 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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Dan Smith]

> 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 thought for sure. However, it would be much better if we
could avoid literally detaching the VIF from the guest and instead just
swap where the other end is plugged into. With virtual infrastructure,
that should be pretty easy to do, unless you're switching actual L2
networks. If you're doing the latter, however, you might as well reboot
the guest I think.

--Dan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Russell Bryant]

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.
> 
>   https://wiki.openstack.org/wiki/MigrateToCinder
> 
> 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?

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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Gary Kotton]

On 1/29/14 7:39 PM, "Russell Bryant"  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@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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Daniel P. Berrange]

On Wed, Jan 29, 2014 at 12:39:23PM -0500, Russell Bryant 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.
> 
> 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.

I was thinking of an upgrade path more akin to what users got when we
removed the nova volume driver, in favour of cinder.

  https://wiki.openstack.org/wiki/MigrateToCinder

ie no guest visible downtime / interuption of service, nor running of
multiple Nova instances in parallel.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Russell Bryant]

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.

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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Daniel P. Berrange]

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.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Dan Smith]

> Effective immediately, I would like to unfreeze nova-network
> development.

I fully support this plan, while also agreeing that Neutron is the
future of networking for OpenStack. As we have seen with recent
performance-related gate failures, we cannot continue to ignore
nova-network while the rest of the system moves forward.

--Dan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Matt Riedemann]

On 1/29/2014 10:47 AM, 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.

First, I would like to say thank you to those in the Neutron team that
have worked hard to make progress in various areas.  While there has
been good progress, we're not quite there on achieving these items.  As
a result, nova-network will *not* be marked deprecated in Icehouse.  We
will revisit this question again in a future release.  I'll leave it to
the Neutron team to comment further on the likelihood of meeting these
goals in the Juno development cycle.

Regarding nova-network, I would like to make some changes.  We froze
development on nova-network in advance of its deprecation.
Unfortunately, this process has taken longer than anyone thought or
hoped.  This has had some negative consequences on the nova-network code
(such as [1]).

Effective immediately, I would like to unfreeze nova-network
development.  What this really means:

   - We will no longer skip nova-network when making general
 architectural improvements to the rest of the code.  An example
 of playing catch-up in nova-network is [2].

   - We will accept new features, evaluated on a case by case basis,
 just like any other Nova feature.  However, we are explicitly
 *not* interested in features that widen the parity gaps between
 nova-network and Neutron.

   - While we will accept incremental features to nova-network, we
 are *not* interested in increasing the scope of nova-network
 to include support of any SDN controller.  We leave that as
 something exclusive to Neutron.

I firmly believe that Neutron is the future of networking for OpenStack.
  We just need to loosen up nova-network to move it along to ease some
pressure and solve some problems as we continue down this transition.

Thanks,

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-January/024052.html
[2] https://blueprints.launchpad.net/nova/+spec/nova-network-objects



Timely thread.  I was just going through nova/neutron-related blueprints 
and patches yesterday for Icehouse and noted these as something I think 
we definitely need as pre-reqs before going all-in with neutron:


https://blueprints.launchpad.net/neutron/+spec/instance-nw-info-api
https://bugs.launchpad.net/nova/+bug/1255594
https://bugs.launchpad.net/nova/+bug/1258620

There are patches up for the two bugs, but they need some work.

--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

[Russell Bryant]

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.

First, I would like to say thank you to those in the Neutron team that
have worked hard to make progress in various areas.  While there has
been good progress, we're not quite there on achieving these items.  As
a result, nova-network will *not* be marked deprecated in Icehouse.  We
will revisit this question again in a future release.  I'll leave it to
the Neutron team to comment further on the likelihood of meeting these
goals in the Juno development cycle.

Regarding nova-network, I would like to make some changes.  We froze
development on nova-network in advance of its deprecation.
Unfortunately, this process has taken longer than anyone thought or
hoped.  This has had some negative consequences on the nova-network code
(such as [1]).

Effective immediately, I would like to unfreeze nova-network
development.  What this really means:

  - We will no longer skip nova-network when making general
architectural improvements to the rest of the code.  An example
of playing catch-up in nova-network is [2].

  - We will accept new features, evaluated on a case by case basis,
just like any other Nova feature.  However, we are explicitly
*not* interested in features that widen the parity gaps between
nova-network and Neutron.

  - While we will accept incremental features to nova-network, we
are *not* interested in increasing the scope of nova-network
to include support of any SDN controller.  We leave that as
something exclusive to Neutron.

I firmly believe that Neutron is the future of networking for OpenStack.
 We just need to loosen up nova-network to move it along to ease some
pressure and solve some problems as we continue down this transition.

Thanks,

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-January/024052.html
[2] https://blueprints.launchpad.net/nova/+spec/nova-network-objects

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev