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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ 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
