It might be possible with iptables or ebtables rules, but it's not planned
that I'm aware of and it would be non-trivial to do. The current
implementation depends heavily on OVS flow rules.[1]
1. https://wiki.openstack.org/wiki/Neutron/DVR_L2_Agent
On Tue, Mar 31, 2015 at 10:37 PM, Dr. Jens
bin7JAxOZOqRl.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
On Fri, 2015-03-27 at 17:01 +, Tim Bell wrote:
From the stats
(http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014),
-43% of production clouds use OVS (the default for Neutron)
-30% of production clouds are Nova network based
-
On 03/30/2015 05:58 PM, Sean M. Collins wrote:
Quick update about OVS vs LB:
Sean M. Collins pushed up a patch that runs CI on Tempest with LB:
https://review.openstack.org/#/c/168423/
So far it's failing pretty badly.
I haven't had a chance to debug the failures - it is my hope that
It's worth pointing out here that the in-tree OVS solution controls traffic
using iptables on regular bridges too. The difference between the two
occurs when it comes to how traffic is separated into different networks.
It's also worth noting that DVR requires OVS as well. If nobody is
Am 01/04/15 um 04:10 schrieb Kevin Benton:
It's worth pointing out here that the in-tree OVS solution controls traffic
using iptables on regular bridges too. The difference between the two
occurs when it comes to how traffic is separated into different networks.
It's also worth noting that DVR
On 28 March 2015 at 00:41, Steve Wormley openst...@wormley.com wrote:
So, I figured I'd weigh in on this as an employee of a nova-network using
company.
Nova-network allowed us to do a couple things simply.
1. Attach openstack networks to our existing VLANs using our existing
- Original Message -
On 03/27/2015 11:48 AM, Assaf Muller wrote:
- Original Message -
On 03/27/2015 05:22 AM, Thierry Carrez wrote:
snip
Part of it is corner (or simplified) use cases not being optimally
served by Neutron, and I think Neutron could more
On 03/30/2015 09:25 AM, Assaf Muller wrote:
- Original Message -
On 03/27/2015 11:48 AM, Assaf Muller wrote:
- Original Message -
On 03/27/2015 05:22 AM, Thierry Carrez wrote:
snip
Part of it is corner (or simplified) use cases not being optimally
served by Neutron,
On 03/26/2015 06:31 PM, Michael Still wrote:
Hi,
I thought it would be a good idea to send out a status update for the
migration from nova-network to Neutron, as there hasn't been as much
progress as we'd hoped for in Kilo. There are a few issues which have
been slowing progress down.
On 03/26/2015 08:58 PM, Russell Bryant wrote:
On 03/26/2015 06:31 PM, Michael Still wrote:
Hi,
I thought it would be a good idea to send out a status update for the
migration from nova-network to Neutron, as there hasn't been as much
progress as we'd hoped for in Kilo. There are a few issues
- Original Message -
On 03/30/2015 09:25 AM, Assaf Muller wrote:
- Original Message -
On 03/27/2015 11:48 AM, Assaf Muller wrote:
- Original Message -
On 03/27/2015 05:22 AM, Thierry Carrez wrote:
snip
Part of it is corner (or simplified) use cases
On 03/30/2015 10:34 AM, Anita Kuno wrote:
On 03/26/2015 08:58 PM, Russell Bryant wrote:
To me it comes down to the reasons people don't want to move. I'd like
to dig into exactly why people don't want to use Neutron. If there are
legitimate reasons why nova-network will work better, then
On Mon, Mar 30, 2015 at 4:49 AM, Jesse Pretorius jesse.pretor...@gmail.com
wrote:
On 28 March 2015 at 00:41, Steve Wormley openst...@wormley.com wrote:
2. Floating IPs managed at each compute node(multi-host) and via the
standard nova API calls.
2 meant we can't use pure provider VLAN
On 03/30/2015 12:35 PM, Russell Bryant wrote:
On 03/30/2015 10:34 AM, Anita Kuno wrote:
On 03/26/2015 08:58 PM, Russell Bryant wrote:
To me it comes down to the reasons people don't want to move. I'd like
to dig into exactly why people don't want to use Neutron. If there are
legitimate
On Sun, Mar 29, 2015 at 6:45 AM, Kevin Benton blak...@gmail.com wrote:
Does the decision about the floating IP have to be based on the use of the
private IP in the original destination, or could you get by with rules on
the L3 agent to avoid NAT just based on the destination being in a
Quick update about OVS vs LB:
Sean M. Collins pushed up a patch that runs CI on Tempest with LB:
https://review.openstack.org/#/c/168423/
So far it's failing pretty badly.
I haven't had a chance to debug the failures - it is my hope that
perhaps there are just more changes I need to make
Does the decision about the floating IP have to be based on the use of the
private IP in the original destination, or could you get by with rules on
the L3 agent to avoid NAT just based on the destination being in a
configured set of CIDRs?
If you could get by with the latter it would be a much
On Sat, Mar 28, 2015 at 1:57 AM, Kevin Benton blak...@gmail.com wrote:
You want floating IPs at each compute node, and DVR with VLAN support got
you close. Are the floating IPs okay being on a different network/VLAN?
I should clarify, the floating IPs are publicly routable addresses, as
] Status of the nova-network to
Neutron migration work
This is a use case that we probably need a better equivalent of on the Neutron
side. It would be great if you could clarify a few things to make sure I
understand it correctly.
You want floating IPs at each compute node, and DVR with VLAN
Kyle Mestery wrote:
On Thu, Mar 26, 2015 at 7:58 PM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:
On 03/26/2015 06:31 PM, Michael Still wrote:
Hi,
I thought it would be a good idea to send out a status update for the
migration from
On 03/27/2015 05:22 AM, Thierry Carrez wrote:
snip
Part of it is corner (or simplified) use cases not being optimally
served by Neutron, and I think Neutron could more aggressively address
those. But the other part is ignorance and convenience: that Neutron
thing is a scary beast, last time I
[mailto:kevin@pnnl.gov]
Sent: 27 March 2015 17:36
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to
Neutron migration work
No, no. Most OpenStack deployments are neutron based with ovs because its the
default
Let's also keep in mind that the ML2 Plugin has *both* openvswitch and
linuxbridge mechanism drivers enabled[1]. If I understand things
correctly, this means this discussion shouldn't turn into a debate about
which mechanism everyone prefers, since *both* are enabled.
There is one thing that we
On Fri, Mar 27, 2015 at 09:31:39AM +1100, Michael Still wrote:
Hi,
I thought it would be a good idea to send out a status update for the
migration from nova-network to Neutron, as there hasn't been as much
progress as we'd hoped for in Kilo. There are a few issues which have
been slowing
On Fri, Mar 27, 2015 at 01:17:48PM EDT, Jay Pipes wrote:
But, there's the rub. Neutron *isn't* attractive to this set of people
because:
a) It doesn't provide for automatic (sub)net allocation for a user or
tenant in the same way that nova-network just Gets This Done for a user
that wants
(not for usage questions)
Subject: Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to
Neutron migration work
On Fri, Mar 27, 2015 at 09:31:39AM +1100, Michael Still wrote:
Hi,
I thought it would be a good idea to send out a status update for the
migration from nova-network to Neutron
On Fri, Mar 27, 2015 at 11:35 AM, Fox, Kevin M kevin@pnnl.gov wrote:
So I would expect the number of folks needing to go from nova-network to
neutron to be a small number of clouds, not a big number. Changing the
defaults now to favor that small minority of clouds, seems like an odd
On 03/27/2015 11:48 AM, Assaf Muller wrote:
- Original Message -
On 03/27/2015 05:22 AM, Thierry Carrez wrote:
snip
Part of it is corner (or simplified) use cases not being optimally
served by Neutron, and I think Neutron could more aggressively address
those. But the other part
- Original Message -
On 03/27/2015 05:22 AM, Thierry Carrez wrote:
snip
Part of it is corner (or simplified) use cases not being optimally
served by Neutron, and I think Neutron could more aggressively address
those. But the other part is ignorance and convenience: that Neutron
Sean Dague s...@dague.net wrote on 03/27/2015 07:11:18 AM:
From: Sean Dague s...@dague.net
To: openstack-dev@lists.openstack.org
Date: 03/27/2015 07:12 AM
Subject: Re: [openstack-dev] [Nova][Neutron] Status of the nova-
network to Neutron migration work
On 03/27/2015 05:22 AM, Thierry
@lists.openstack.org
Subject: Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to
Neutron migration work
On 03/27/2015 05:22 AM, Thierry Carrez wrote:
snip
Part of it is corner (or simplified) use cases not being optimally
served by Neutron, and I think Neutron could more aggressively
Inline…
On Mar 27, 2015, at 11:48 AM, Assaf Muller amul...@redhat.com wrote:
- Original Message -
On 03/27/2015 05:22 AM, Thierry Carrez wrote:
snip
Part of it is corner (or simplified) use cases not being optimally
served by Neutron, and I think Neutron could more aggressively
: [openstack-dev] [Nova][Neutron] Status of the nova-network to
Neutron migration work
On Fri, Mar 27, 2015 at 10:48 AM, Assaf Muller
amul...@redhat.commailto:amul...@redhat.com wrote:
Looking at the latest user survey, OVS looks to be 3 times as popular as
Linux bridge for production deployments
On Fri, Mar 27, 2015 at 11:11:42AM EDT, Mohammad Banikazemi wrote:
Are you suggesting that for the common use cases that will use the default
setup, the external network connectivity doesn't matter much?
No, if anything the reverse. The default will have external connectivity
by default, by
On Fri, Mar 27, 2015 at 10:48 AM, Assaf Muller amul...@redhat.com wrote:
Looking at the latest user survey, OVS looks to be 3 times as popular as
Linux bridge for production deployments. Having LB as the default seems
like an odd choice. You also wouldn't want to change the default before
LB
So, I figured I'd weigh in on this as an employee of a nova-network using
company.
Nova-network allowed us to do a couple things simply.
1. Attach openstack networks to our existing VLANs using our existing
firewall/gateway and allow easy access to hardware such as database servers
and storage
On 03/26/2015 06:31 PM, Michael Still wrote:
Hi,
I thought it would be a good idea to send out a status update for the
migration from nova-network to Neutron, as there hasn't been as much
progress as we'd hoped for in Kilo. There are a few issues which have
been slowing progress down.
On Thu, Mar 26, 2015 at 7:58 PM, Russell Bryant rbry...@redhat.com wrote:
On 03/26/2015 06:31 PM, Michael Still wrote:
Hi,
I thought it would be a good idea to send out a status update for the
migration from nova-network to Neutron, as there hasn't been as much
progress as we'd hoped
39 matches
Mail list logo
