<p dir="ltr">>Ultimately, we need to match up the host scheduled by Nova to the<br>
addresses available to that host.  We could do this by delaying<br>
address assignment until after host binding or we could do it by<br>
including segment information from Neutron during scheduling.  The<br>
latter has the advantage that we can consider IP availability during<br>
scheduling.  That is why GoDaddy implemented it that way.</p>
<p dir="ltr">Including segment information to Nova only solves the issue of ruling out hosts that don't have access to the network that the port is bound to. We still have to solve the issue of selecting the network for a given host in the first place. Scheduling filters don't choose things like which resource to use, they only choose which hosts can satisfy the constraints of the chosen resources.</p>
<p dir="ltr">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]</p>
<p dir="ltr">>the neutron network might have been conceived as being just "a broadcast domain" but, in practice, it is L2 and L3.</p>
<p dir="ltr">I disagree with this and I think we need to be very clear on what our API constructs mean. If we don't, we will have constant proposals to smear the boundaries between things, which is sort of what we are running into already.</p>
<p dir="ltr">Today I can create a standalone network and attach ports to it. That network is just an L2 broadcast domain and has no IP addresses or any L3 info associated with it, but the ports can communicate via L2. The network doesn't know anything about the l3 addresses and just forwards the traffic according to L2 semantics. </p>
<p dir="ltr">The neutron subnet provides L3 addressing info that can be associated with an arbitrary neutron network. To route between subnets, we attach routers to subnets. It doesn't matter if those subnets are on the same or different networks, because it's L3 and it doesn't matter.</p>
<p dir="ltr">It is conceivable that we could remove the requirement for a subnet to have an underlying network in the fully-routed case. However, that would mean we would need to remove the requirement for a port to have a network as well (unless this is only used for floating IPs).</p>
<p dir="ltr">1. <a href="https://bugs.launchpad.net/neutron/+bug/1469668">https://bugs.launchpad.net/neutron/+bug/1469668</a></p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jul 21, 2015 at 1:11 PM, John Belamaric <<a href="mailto:jbelamaric@infoblox.com">jbelamaric@infoblox.com</a>> wrote:<br>
> Wow, a lot to digest in these threads. If I can summarize my understanding<br>
> of the two proposals. Let me know whether I get this right. There are a<br>
> couple problems that need to be solved:<br>
><br>
>  a. Scheduling based on host reachability to the segments<br>
>  b. Floating IP functionality across the segments. I am not sure I am clear<br>
> on this one but it sounds like you want the routers attached to the segments<br>
> to advertise routes to the specific floating IPs. Presumably then they would<br>
> do NAT or the instance would assign both the fixed IP and the floating IP to<br>
> its interface?<br>
><br>
> In Proposal 1, (a) is solved by associating segments to the front network<br>
> via a router - that association is used to provide a single hook into the<br>
> existing API that limits the scope of segment selection to those associated<br>
> with the front network. (b) is solved by tying the floating IP ranges to the<br>
> same front network and managing the reachability with dynamic routing.<br>
><br>
> In Proposal 2, (a) is solved by tagging each network with some meta-data<br>
> that the IPAM system uses to make a selection. This implies an IP allocation<br>
> request that passes something other than a network/port to the IPAM<br>
> subsystem. This fine from the IPAM point of view but there is no<br>
> corresponding API for this right now. To solve (b) either the IPAM system<br>
> has to publish the routes or the higher level management has to ALSO be<br>
> aware of the mappings (rather than just IPAM).<br>
<br>
John, from your summary above, you seem to have the best understanding<br>
of the whole of what I was weakly attempting to communicate.  Thank<br>
you for summarizing.<br>
<br>
> To throw some fuel on the fire, I would argue also that (a) is not<br>
> sufficient and address availability needs to be considered as well (as<br>
> described in [1]). Selecting a host based on reachability alone will fail<br>
> when addresses are exhausted. Similarly, with (b) I think there needs to be<br>
> consideration during association of a floating IP to the effect on routing.<br>
> That is, rather than a huge number of host routes it would be ideal to<br>
> allocate the floating IPs in blocks that can be associated with the backing<br>
> networks (though we would want to be able to split these blocks as small as<br>
> a /32 if necessary - but avoid it/optimize as much as possible).<br>
<br>
Yes, address availability is a factor and must be considered in either<br>
case.  My email was getting long already and I thought that could be<br>
considered separately since I believe it applies regardless of the<br>
outcome of this thread.  But, since it seems to be an essential part<br>
of this conversation, let me say something about it.<br>
<br>
Ultimately, we need to match up the host scheduled by Nova to the<br>
addresses available to that host.  We could do this by delaying<br>
address assignment until after host binding or we could do it by<br>
including segment information from Neutron during scheduling.  The<br>
latter has the advantage that we can consider IP availability during<br>
scheduling.  That is why GoDaddy implemented it that way.<br>
<br>
> In fact, I think that these proposals are more or less the same - it's just<br>
> in #1 the meta-data used to tie the backing networks together is another<br>
> network. This allows it to fit in neatly with the existing APIs. You would<br>
> still need to implement something prior to IPAM or within IPAM that would<br>
> select the appropriate backing network.<br>
<br>
They are similar but to say they're the same is going a bit too far.<br>
If they were the same then we'd be done with this conversation.  ;)<br>
<br>
> As a (gulp) third alternative, we should consider that the front network<br>
> here is in essence a layer 3 domain, and we have modeled layer 3 domains as<br>
> address scopes in Liberty. The user is essentially saying "give me an<br>
> address that is routable in this scope" - they don't care which actual<br>
> subnet it gets allocated on. This is conceptually more in-line with [2] -<br>
> modeling L3 domain separately from the existing Neutron concept of a network<br>
> being a broadcast domain.<br>
<br>
I will consider this some more.  This is an interesting thought.<br>
Address scopes and subnet pools could play a role here.  I don't yet<br>
see how it can all fit together but it is worth some thought.<br>
<br>
One nit:  the neutron network might have been conceived as being just<br>
"a broadcast domain" but, in practice, it is L2 and L3.  The Neutron<br>
subnet is not really an L3 construct; it is just a cidr and doesn't<br>
make sense on its own without considering its association with a<br>
network and the other subnets associated with the same network.<br>
<br>
> Fundamentally, however we associate the segments together, this comes down<br>
> to a scheduling problem. Nova needs to be able to incorporate data from<br>
> Neutron in its scheduling decision. Rather than solving this with a single<br>
> piece of meta-data like network_id as described in proposal 1, it probably<br>
> makes more sense to build out the general concept of utilizing network data<br>
> for nova scheduling. We could still model this as in #1, or using address<br>
> scopes, or some arbitrary data as in #2. But the harder problem to solve is<br>
> the scheduling, not how we tag these things to inform that scheduling.<br>
<br>
Yet how we tag these things seems to be a significant point of<br>
interest.  Maybe not with you but with Ian and Assaf it certainly is.<br>
<br>
As I said above, I agree that the scheduling part is very important<br>
and needs to be discussed but I still separate them in my mind from<br>
this question.<br>
<br>
> The optimization of routing for floating IPs is also a scheduling problem,<br>
> though one that would require a lot more changes to how FIP are allocated<br>
> and associated to solve.<br>
><br>
> John<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/180803/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/180803/</a><br>
> [2] <a href="https://bugs.launchpad.net/neutron/+bug/1458890/comments/7" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1458890/comments/7</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>