Open Stack

Hi Carl,

Sorry for the slow reply.

I think that both of these can be solved with the existing interface, by expanding the different types of "request" objects. Right now, we have very basic and limited requests: SpecificSubnet, AnySubnet. There is no reason we can't create a subnet request that includes tag (or host or segment) information that can be used by the existing IPAM driver methods. If the tag is an optional refinement, then the request type can subclass the existing AnySubnet request; otherwise, the request would need to be rejected by the driver.

Each driver can deliver its own factory for converting create_subnet (etc.) API requests into IPAM request objects. Thus, each driver can decide whether it supports some incoming request type or not. This same mechanism that applies to subnet also applies to IPs.

One thing we may want to consider, though, is discoverability of these capabilities. We have this now for extensions in general, of course. But in this case, we would want to be able to discover whether or not the IPAM driver supports this functionality, before enabling the use of the routed segments feature. As far as I know, we don't today provide a way to discover whether a particular feature works with a particular plugin or other extension. That is, I don't think we allow extensions to specify that they are dependent on other specific extensions, do we?

John

> On Mar 11, 2016, at 6:15 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:
> 
> Hi,
> 
> 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.  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.  Obviously, we wouldn't require
> implementations to support it but routed networks wouldn't be very
> useful without it.  So, those implementations would not be compatible
> when routed networks are deployed.
> 
> 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.
> 
> 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