List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 07/28/2015 06:46 PM
Subject: Re: [openstack-dev] [Neutron][L3] Representing a networks
connected by routers
We need to work on that code quite a bit anyway for other features
(get me a network, VLAN trunk ports) so
You're right but in the current model you can't have IP addresses without
the network either which is actually the point I'm trying to make.
Definitely, but it's not because the network has properties that IPAM
depends on. It's only because a subnet has a non-nullable foreign key
relationship to
Kevin,
This is just a final top-post to say that I'm going to spend the next
week noodling over this discussion in more detail and trying to flesh
it out into a proposal. I think we're pretty much in agreement about
where the problems are in the model. It feels like we'll just be
beating a dead
Kevin, sorry for the delay in response. Keeping up on this thread was
getting difficult while on vacation.
tl;dr: I think it is worth it to talk through the idea of inserting
some sort of a subnet group thing in the model to which floating ips
(and router external gateways) will associate. It
Also, in my proposal, it is more the router that is the grouping mechanism.
I can't reconcile this with all of the points you make in the rest of your
email. You want the collection of subnets that a network represents, but
you don't want any other properties of the network.
that the network
@lists.openstack.org
Date: 07/28/2015 06:46 PM
Subject: Re: [openstack-dev] [Neutron][L3] Representing a networks
connected by routers
We need to work on that code quite a bit anyway for other features
(get me a network, VLAN trunk ports) so adding a different parameter
shouldn't be bad. Even
We need to work on that code quite a bit anyway for other features (get me
a network, VLAN trunk ports) so adding a different parameter shouldn't be
bad. Even if Nova doesn't initially buy in, we can always pre-create the
port and pass it to Nova boot as a UUID.
On Tue, Jul 28, 2015 at 6:15 AM,
Kevin, doesn't this in itself create technical debt on the nova side in the
sense of what an instance attaches to?
I agree that it looks like less technical debt than conditionally
redefining a network, but without nova buy-in, it looks
like a non-starter...
Ryan
Kevin Benton blak...@gmail.com
- Original Message -
On 7/23/15, 9:42 AM, Carl Baldwin c...@ecbaldwin.net wrote:
On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton blak...@gmail.com wrote:
The issue with the availability zone solution is that we now force
availability zones in Nova to be constrained to network
On 7/23/15, 8:54 AM, Carl Baldwin c...@ecbaldwin.net wrote:
On Thu, Jul 23, 2015 at 8:51 AM, Kevin Benton blak...@gmail.com wrote:
Or, migration scheduling would need to respect the constraint that a
port may be confined to a set of hosts. How can be assign a port to a
different network? The
On 7/23/15, 9:42 AM, Carl Baldwin c...@ecbaldwin.net wrote:
On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton blak...@gmail.com wrote:
The issue with the availability zone solution is that we now force
availability zones in Nova to be constrained to network configuration.
In
the L3 ToR/no
, July 27, 2015 7:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L3] Representing a networks connected by
routers
On 7/23/15, 8:54 AM, Carl Baldwin c...@ecbaldwin.net wrote:
On Thu, Jul 23, 2015 at 8:51 AM, Kevin Benton blak
On Jul 23, 2015 6:04 PM, Kevin Benton blak...@gmail.com wrote:
IOW, I don't think what I
proposed in adding L3 stuff to the network that wasn't already here.
The point I'm trying to make is that there isn't any L3 stuff on the
network itself. There are L3 things that depend on the network
On Jul 23, 2015 8:39 PM, Paul Carver pcar...@paulcarver.us wrote:
I think Kevin is right here. Network is fundamentally a layer 2
construct, it represents direct reachability. A network could in principle
support non-IP traffic (though in practice that may or may not work
depending on underlying
On Thu, Jul 23, 2015 at 1:45 PM, Kevin Benton blak...@gmail.com wrote:
We ran in to this long ago.
What are some other examples? We've be good about keeping the network L2
only. Segments, VLAN transparency, and other properties of the network are
all L2.
Another thing is that we create
IOW, I don't think what I
proposed in adding L3 stuff to the network that wasn't already here.
The point I'm trying to make is that there isn't any L3 stuff on the
network itself. There are L3 things that depend on the network because an
L2 network carries them. But the routed network proposes
On 7/23/2015 2:45 PM, Kevin Benton wrote:
We ran in to this long ago.
What are some other examples? We've be good about keeping the network L2
only. Segments, VLAN transparency, and other properties of the network are
all L2.
The example you gave about needing the network to see the grouping
On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton blak...@gmail.com wrote:
It seems to me that the existence of the multiprovider extension is an
important point for this discussion. Multiprovider, as I understand it,
allows describing a network composed of multiple L2 segments with implicit
Or, migration scheduling would need to respect the constraint that a
port may be confined to a set of hosts. How can be assign a port to a
different network? The VM would wake up and what? How would it know
to reconfigure its network stack?
Right, that's a big mess. Once a network is picked
On Thu, Jul 23, 2015 at 8:51 AM, Kevin Benton blak...@gmail.com wrote:
Or, migration scheduling would need to respect the constraint that a
port may be confined to a set of hosts. How can be assign a port to a
different network? The VM would wake up and what? How would it know
to reconfigure
On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton blak...@gmail.com wrote:
The issue with the availability zone solution is that we now force
availability zones in Nova to be constrained to network configuration. In
the L3 ToR/no overlay configuration, this means every rack is its own
availability
On Tue, Jul 21, 2015 at 8:41 AM, Salvatore Orlando
salv.orla...@gmail.com wrote:
It is however important to ensure services like DHCP keep working as usual.
Treating segments as logical networks in their own right is the simples
solution to achieve this imho.
Agreed.
While the logical model
We ran in to this long ago.
What are some other examples? We've be good about keeping the network L2
only. Segments, VLAN transparency, and other properties of the network are
all L2.
The example you gave about needing the network to see the grouping of
subnets isn't the network leaking into L3,
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L3] Representing a networks connected by
routers
On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton blak...@gmail.com wrote:
I proposed the port scheduling RFE to deal with the part about
selecting
On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton blak...@gmail.com wrote:
I proposed the port scheduling RFE to deal with the part about selecting a
network that is appropriate for the port based on provided hints and
host_id. [1]
Thanks for the pointer. I hadn't paid much attention to this RFE
On 21/07/15 15:45, Salvatore Orlando wrote:
On 21 July 2015 at 14:21, Neil Jerram neil.jer...@metaswitch.com
mailto:neil.jer...@metaswitch.com wrote:
You've probably seen Robert Kukura's comment on the related bug at
https://bugs.launchpad.net/neutron/+bug/1458890/comments/30, and
I added a summary of my thoughts about the enhancements I think we could
make to the Nova scheduler in order to better support the Neutron provider
networks use case.
- Original Message -
On Tue, Jul 21, 2015 at 1:11 PM, John Belamaric jbelama...@infoblox.com
wrote:
Wow, a lot to
This implies an IP allocation request that passes something other than a
network/port to the IPAM subsystem.
What I forgot to mention in my previous email is that proposal #2 is basically
a feature we are planning for our custom IPAM driver (without the routing
piece). We allow arbitrary
It seems to me that the existence of the multiprovider extension is
an important point for this discussion. Multiprovider, as I understand
it, allows describing a network composed of multiple L2 segments
with implicit east-west routing between them.
Not quite. Multiprovider is to describe
Ultimately, we need to match up the host scheduled by Nova to the
addresses available to that host. We could do this by delaying
address assignment until after host binding or we could do it by
including segment information from Neutron during scheduling. The
latter has the advantage that we can
The issue with the availability zone solution is that we now force
availability zones in Nova to be constrained to network configuration. In
the L3 ToR/no overlay configuration, this means every rack is its own
availability zone. This is pretty annoying for users to deal with because
they have to
- Original Message -
The issue with the availability zone solution is that we now force
availability zones in Nova to be constrained to network configuration. In
the L3 ToR/no overlay configuration, this means every rack is its own
availability zone. This is pretty annoying for
On Tue, Jul 21, 2015 at 1:11 PM, John Belamaric jbelama...@infoblox.com wrote:
Wow, a lot to digest in these threads. If I can summarize my understanding
of the two proposals. Let me know whether I get this right. There are a
couple problems that need to be solved:
a. Scheduling based on
On 21/07/15 01:47, Assaf Muller wrote:
- Original Message -
I'm looking for feedback from anyone interest but, in particular, I'd
like feedback from the following people for varying perspectives:
Mark McClain (proposed alternate), John Belamaric (IPAM), Ryan Tidwell
(BGP), Neil
A few comments inline.
Generally speaking the only thing I'd like to remark is that this use case
makes sense independently of whether you are using overlay, or any other
SDN solution (whatever SDN means to you).
Also, please note that this thread is now split in two - there's a new
branch
On Jul 20, 2015 4:26 PM, Ian Wells ijw.ubu...@cack.org.uk wrote:
There are two routed network models:
- I give my VM an address that bears no relation to its location and
ensure the routed fabric routes packets there - this is very much the
routing protocol method for doing things where I have
On 21 July 2015 at 07:52, Carl Baldwin c...@ecbaldwin.net wrote:
Now, you seem to generally be thinking in terms of the latter model,
particularly since the provider network model you're talking about fits
there. But then you say:
Actually, both. For example, GoDaddy assigns each vm an ip
Wow, a lot to digest in these threads. If I can summarize my understanding of
the two proposals. Let me know whether I get this right. There are a couple
problems that need to be solved:
a. Scheduling based on host reachability to the segments
b. Floating IP functionality across the segments.
On 21 July 2015 at 12:11, John Belamaric jbelama...@infoblox.com wrote:
Wow, a lot to digest in these threads. If I can summarize my
understanding of the two proposals. Let me know whether I get this right.
There are a couple problems that need to be solved:
a. Scheduling based on host
On 20/07/15 18:36, Carl Baldwin wrote:
I'm looking for feedback from anyone interest but, in particular, I'd
like feedback from the following people for varying perspectives:
Mark McClain (proposed alternate), John Belamaric (IPAM), Ryan Tidwell
(BGP), Neil Jerram (L3 networks), Aaron Rosen
On 20/07/15 23:27, Ian Wells wrote:
There are two routed network models:
- I give my VM an address that bears no relation to its location and ensure the
routed fabric routes packets there - this is very much the routing protocol
method for doing things where I have injected a route into the
[Sorry, mistaken send as mixed format, so quoting may not have come out
right. Hope this time is better...]
On 20/07/15 23:27, Ian Wells wrote:
There are two routed network models:
- I give my VM an address that bears no relation to its location and
ensure the routed fabric routes packets
- Original Message -
I'm looking for feedback from anyone interest but, in particular, I'd
like feedback from the following people for varying perspectives:
Mark McClain (proposed alternate), John Belamaric (IPAM), Ryan Tidwell
(BGP), Neil Jerram (L3 networks), Aaron Rosen (help
There are two routed network models:
- I give my VM an address that bears no relation to its location and ensure
the routed fabric routes packets there - this is very much the routing
protocol method for doing things where I have injected a route into the
network and it needs to propagate. It's
44 matches
Mail list logo
