[Sorry, mistaken send as mixed format, so quoting may not have come out right. Hope this time is better...]
On 20/07/15 23:27, Ian Wells wrote: > There are two routed network models: > > - I give my VM an address that bears no relation to its location and > ensure the routed fabric routes packets there - this is very much the > routing protocol method for doing things where I have injected a route > into the network and it needs to propagate. It's also pretty useless > because there are too many host routes in any reasonable sized cloud. > > - I give my VM an address that is based on its location, which only > becomes apparent at binding time. This means that the semantics of a > port changes - a port has no address of any meaning until binding, > because its location is related to what it does - and it leaves open > questions about what to do when you migrate. > > Now, you seem to generally be thinking in terms of the latter model, > particularly since the provider network model you're talking about > fits there. Right. > But then you say: > > On 20 July 2015 at 10:33, Carl Baldwin <[email protected] > <mailto:[email protected]>> wrote: > > When creating a > port, the binding information would be sent to the IPAM system and the > system would choose an appropriate address block for the allocation. > > > No, it wouldn't, because creating and binding a port are separate > operations. I can't give the port a location-specific address on > creation - not until it's bound, in fact, which happens much later. Thanks, good point. And does IP allocation currently happen when a port is _created_? (By the way, (1) any faults in the IPAM-related proposal are really mine, not Carl's; he's just trying to present my half-baked idea as fairly as he can; (2) therefore I really appreciate your feedback on it!) > > On proposal 1: consider the cost of adding a datamodel to Neutron. It > has to be respected by all developers, it frequently has to be > deployed by all operators, and every future change has to align with > it. Plus either it has to be generic or optional, and if optional > it's a burden to some proportion of Neutron developers and users. I suppose any Neutron API enhancement will have some cost, and proposal 1 has the one specific aspect that Mark McClain pointed out, that ports end up with a backing network ID, not the front network ID, and that that may surprise a lot of existing plugin code. I don't really see your "has to be deployed by all operators", "every future change has to align with it" and "if optional it's a burden ..." points, though. > I accept proposal 1 is easy, but it's not universally applicable. > It doesn't work with Neil Jerram's plans, I'm not sure that this current discussion has to address _all_ possible use cases. To be clear about what you mean, though: do you mean that representing [routed] in terms of proposal 1 would require a backing network for each VM? (If so, I agree that that wouldn't be good!) [routed] https://review.openstack.org/#/c/198439/ > it doesn't work with multiple interfaces per host, Why not? > and it doesn't work with the IPv6 routed-network model I worked on. Can you give a pointer? > > Given that, I wonder whether proposal 2 could be rephrased. > > 1: some network types don't allow unbound ports to have addresses, > they just get placeholder addresses for each subnet until they're bound Should that say "some network types allow unbound ports not to have addresses"? > 2: 'subnets' on these networks are more special than subnets on other > networks. (More accurately, they dont use subnets. It's a shame > subnets are core Neutron, because they're pretty horrible and yet hard > to replace.) Not sure on your exact point here, but what about new subnet pools? > 3: there's an independent (in an extension? In another API endpoint?) > datamodel that the network points to and that IPAM refers to to find a > port an address. Bonus, people who aren't using funky network types > can disable this extension. Well that would be IPAM-module-internal anyway; I'd say that - at least during phase 1 - it could do whatever it likes to work out sensible IP allocation. Longer term, sure, one could create a formal datamodel for this. > 4: when the port is bound, the IPAM is referred to, and it's told the > binding information of the port. > 5: when binding the port, once IPAM has returned its address, the > network controller probably does stuff with that address when it > completes the binding (like initialising routing). I believe it's already supported for a port's fixed IPs to change - so hopefully nothing particularly new here. > 6: live migration either has to renumber a port or forward old traffic > to the new address via route injection. This is an open question now, > so I'm mentioning it rather than solving it. > > In fact, adding that hook to IPAM at binding plus setting aside a 'not > set' IP address might be all you need to do to make it possible. The > IPAM needs data to work out what an address is, but that doesn't have > to take the form of existing Neutron constructs. Thanks! That's very much what I was thinking too, so really appreciate your support and adding useful flesh to the bone. Regards, Neil __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
