Open Stack

On Mon, Mar 21, 2016 at 12:52 PM, John Belamaric
<jbelamaric at infoblox.com> wrote:
> Sorry for the slow reply.

And, sorry for mine.  I was distracted with dotting I's and crossing
T's on some other things.  I'm now back to playing around with this.

> 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.

I would argue that expand the requests is changing the interface.  At
least, that is the way I see it.

> 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.

I'll play around with this.

> 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?

We do need to figure this out.  If IPAM doesn't support the feature
then we probably shouldn't allow associating subnets to segments.
That would effectively disable the feature.

Carl