Open Stack

[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 <carl at ecbaldwin.net
> <mailto:carl at ecbaldwin.net>> 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