On Mon, Mar 21, 2016 at 12:52 PM, John Belamaric <jbelama...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
