Open Stack

On 11/03/16 23:20, Carl Baldwin wrote:
> Hi,

Hi Carl, and sorry for the lateness of this reply.

> I have started to get into coding [1] for the Neutron routed networks
> specification [2].
>
> This spec proposes a new association between network segments and
> subnets.  This affects how IPAM needs to work because until we know
> where the port is going to land, we cannot allocate an IP address for
> it.

Note: according to the text and discussion at 
https://review.openstack.org/#/c/263898/, Neutron actually _does_ 
already know where the port is going to land (i.e. the chosen host) at 
the time when it is first allocating an IP address.  At least in the 
most common case, which is when the user request is "launch instance(s) 
on <xxx> network".

> Also, IPAM will need to somehow be aware of segments.  We have
> proposed a host / segment mapping which could be transformed to a host
> / subnet mapping for IPAM purposes.
>
> I wanted to get the opinion of folks like Salvatore, John Belamaric,
> and you (if you interested) on this.  How will this affect the
> interface to pluggable IPAM and how can pluggable implementations can
> accommodate this change.

Well, first of all we have a problem that the pluggable IPAM interface 
is not documented as it is already.  So it is tricky to comment at all 
on how that interface might need to change. :-)

Petra Sargent, with a little of my help, has started documenting the 
interface at https://review.openstack.org/#/c/289460/, but I think there 
is still lots more to be said there - so I would encourage anyone with 
existing knowledge of the IPAM interface to go there and contribute 
useful chunks of extra explanatory text.

With that as a big caveat, here are my thoughts so far.  The pluggable 
IPAM interface has core Neutron code on one side, and pluggable IPAM 
drivers on the other.  As a general principle, it's better if we can 
keep complexity on the core side, and keep the IPAM drivers as simple as 
possible to write and maintain; because there is only one Neutron core, 
and there will in future be many IPAM drivers.

I believe it's already the case that the core tells the driver about the 
subnet(s) that the driver can allocate an IP from.  (Although I'm not 
sure exactly what form that takes, and also if the subnet(s) is/are 
specified on a per-instance basis or per-group of instances, or 
something else.)  Therefore, in the case where segments are being used, 
and subnets are defined with affinity to those segments, the core could 
handle that by reducing the set of subnets that it offers to the driver; 
and that would not require any change to existing IPAM drivers.

At least in the first implementation, I would _not_ pass any new 
segment-specific information over the pluggable IPAM interface (i.e. to 
the driver), because I don't see any reason for the driver to need this; 
I think it's better to contain the handling of that within the Neutron core.

I believe that the core does _not_ tell the driver about the chosen host 
for the port for which an IP allocation is wanted (i.e. 
port['binding:host_id']).  I would like this information to be passed to 
the driver, so as to enable cases where some kind of host-subnet 
affinity is desirable, but that affinity cannot be described by Neutron 
segment objects.  So in this case the driver should receive

- all of the subnet(s) that are defined for the relevant Network

- the chosen host

and it would use its own out-of-band knowledge to decide how to allocate 
an IP from some subrange of the available subnet(s), depending on the 
chosen host.

Finally, I believe that the current pluggable IPAM interface technically 
already allows the last paragraph to be achieved - but that it is pretty 
hard and complex to do that, as it requires subclassing many classes. 
Assuming I'm right about that, I don't think that such a simple 
interface enhancement should require so much work, and hence I'd prefer 
binding:host_id to be added to the core interface.

>  Obviously, we wouldn't require
> implementations to support it

"implementations" = existing IPAM drivers, here?  I think what we need 
can be done in a way such that there is no "it" for them to support.

> but routed networks wouldn't be very
> useful without it.

Here, I assume that "it" means "allocating IPs in a host- or 
segment-dependent way", and I agree with you that this is a practical 
requirement for large scale routed network usage.

>  So, those implementations would not be compatible
> when routed networks are deployed.

(Again, I think we shouldn't need to say this.)

> Another related topic was brought up in the recent Neutron mid-cycle.
> We talked about adding a service type attribute to to subnets.  The
> reason for this change is to allow operators to create special subnets
> on a network to be used only by certain kinds of ports.  For example,
> DVR fip namespace gateway ports burn a public IP for no good reason.
> This new feature would allow operators to create a special subnet in
> the network with private addressing only to be used by these ports.
>
> Another example would give operators the ability to use private
> subnets for router external gateway ports if shared SNAT is not needed
> or doesn't need to use public IPs.
>
> These are two ways in which subnets are taking on extra
> characteristics which distinguish them from other subnets on the same
> network.  That is why I lumped them together in to one thread.

Slightly related, do you happen to know what happens when a Network has 
multiple IPv4 subnets?  Which one gets used for the IPv4 allocation?

(Also FWIW I personally don't yet understand how subnet pools and 
address scopes come into play here, but I guess they probably do!)

I hope some of that is useful.

Regards,
	Neil


> Carl
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>