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

2014-02-17 Thread Matt Riedemann



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

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

On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh cbky...@gmail.com
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

2014-01-30 Thread 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

2014-01-30 Thread 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

2014-01-30 Thread Christopher Yeoh
On Thu, Jan 30, 2014 at 2:08 PM, Michael Still mi...@stillhq.com wrote:

 On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh 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


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

2014-01-30 Thread Russell Bryant
On 01/30/2014 08:10 AM, Christopher Yeoh wrote:
 On Thu, Jan 30, 2014 at 2:08 PM, Michael Still mi...@stillhq.com
 mailto:mi...@stillhq.com wrote:
 
 On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh cbky...@gmail.com
 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.

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

2014-01-30 Thread Russell Bryant
On 01/29/2014 05:24 PM, Kyle Mestery wrote:
 
 On Jan 29, 2014, at 12:04 PM, Russell Bryant rbry...@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.

  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

2014-01-30 Thread Christopher Yeoh
On Fri, Jan 31, 2014 at 12:27 AM, Russell Bryant rbry...@redhat.com wrote:

 On 01/30/2014 08:10 AM, Christopher Yeoh wrote:
  On Thu, Jan 30, 2014 at 2:08 PM, Michael Still mi...@stillhq.com
  mailto:mi...@stillhq.com wrote:
 
  On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh cbky...@gmail.com
  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.

 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

2014-01-30 Thread Russell Bryant
On 01/30/2014 09:13 AM, Christopher Yeoh wrote:
 
 On Fri, Jan 31, 2014 at 12:27 AM, Russell Bryant rbry...@redhat.com
 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

2014-01-30 Thread 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 rbry...@redhat.com
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.


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

2014-01-30 Thread 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

2014-01-30 Thread Christopher Yeoh
On Fri, Jan 31, 2014 at 3:21 AM, Dan Smith d...@danplanet.com 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

2014-01-29 Thread 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


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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread Gary Kotton


On 1/29/14 7:39 PM, Russell Bryant rbry...@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@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=L%2FurKFNkdV1Uy8T0anh
nW56lLyvFw%2BDQxjEDvp4Ji5I%3D%0As=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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread Vishvananda Ishaya

On Jan 29, 2014, at 10:45 AM, Dan Smith d...@danplanet.com 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

2014-01-29 Thread 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

2014-01-29 Thread 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

2014-01-29 Thread Kyle Mestery

On Jan 29, 2014, at 12:04 PM, Russell Bryant rbry...@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.
 
  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

2014-01-29 Thread Christopher Yeoh
On Thu, Jan 30, 2014 at 4:34 AM, Russell Bryant rbry...@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.
 
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

2014-01-29 Thread Michael Still
On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh 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?

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

2014-01-29 Thread 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 tim.b...@cern.ch 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

2014-01-29 Thread Jesse Pretorius
On 29 January 2014 23:13, Vishvananda Ishaya vishvana...@gmail.com 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 harlo...@yahoo-inc.com 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