Open Stack

On 21 July 2015 at 07:52, Carl Baldwin <carl at ecbaldwin.net> wrote:

> > 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.  But then you say:
>
> Actually, both.  For example, GoDaddy assigns each vm an ip from the
> location based address blocks and optionally one from the routed location
> agnostic ones.  I would also like to assign router ports out of the
> location based blocks which could host floating ips from the other blocks.
>
Well, routed IPs that are not location-specific are no different to normal
ones, are they?  Why do they need special work that changes the API?

> > On 20 July 2015 at 10:33, Carl Baldwin <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.
>
> Implicit in both is a need to provide at least a hint at host binding.
> Or, delay address assignment until binding.  I didn't mention it because my
> email was already long.
> This is something and discussed but applies equally to both proposals.
>
No, it doesn't - if the IP address is routed and not relevant to the
location of the host then yes, you would want to *inject a route* at
binding, but you wouldn't want to delay address assignment till binding
because it's location-agnostic.

> > 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.
> >
> > 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 accept proposal 1 is easy,
> but it's not universally applicable.  It doesn't work with Neil Jerram's
> plans, it doesn't work with multiple interfaces per host, and it doesn't
> work with the IPv6 routed-network model I worked on.
>
> Please be more specific.  I'm not following your argument here.  My
> proposal doesn't really add much new data model.
>
My point is that there's a whole bunch of work there to solve the question
of 'how do I allocate addresses to a port when addresses are location
specific' that assumes that there's one model for location specific
addresses that is a bunch of segments with each host on one segment.  I can
break this model easily.  Per the previous IPv6 proposal, I might choose my
address with more care than just by its location, to contain extra
information I care about.  I might have multiple segments connected to one
host where either segment will do and the scheduler should choose the most
useful one.

If this whole model is built using reusable-ish concepts like networks, and
adds a field to ports, then basically it ends up in, or significantly
affecting, the model of core Neutron.  Every Neutron developer to come will
have to read it, understand it, and not break it.  Depending on how it's
implemented, every operator that comes along will have to deploy it and may
be affected by bugs in it (though that depends on precisely how much ends
up as an extension).

If we find a more general purpose interface - and per above, mostly the
interface is 'sometimes I want to pick my address only at binding' plus
'IPAM and address assignment is more complex than the subnet model we have
today' then potentially these datamodels can be specific to IPAM - and not
general purpose 'we have these objects around already' things we're reusing
- and with a clean interface the models may not even be present as code
into a deployed system, which is the best proof they are not introducing
bugs.

Every bit of cruft we write, we have to carry.  It makes more sense to make
the core extensible for this case, in my mind, than it does to introduce it
into the core.

> We've discussed this with Neil at length.  I haven't been able to
> reconcile our respective approaches in to one model that works for both of
> us and still provides value.
>
QED.


> Could you provide some links so that I can brush up on your ipv6 routed
> network model?  I'd like to consider it but I don't know much about it.
>

The best writeup I have is
http://datatracker.ietf.org/doc/draft-baker-openstack-ipv6-model/?include_text=1
(don't judge it by the place it was filed). But the concept was that (a)
VMs received v6 addresses, (b) they were location specific, (c) each had
their own L2 segment (per Neil's idea, and really the ultimate use of this
model), and (d) there was information in the address additional to just its
location and the entropy of choosing a random address.

>
> > 1: some network types don't allow unbound ports to have addresses, they
> just get placeholder addresses for each subnet until they're bound
> > 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.)
> > 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.
> > 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).
> > 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.
>
> I left out the migration issue from my email also because it also affects
> both proposals equally.
>
Understood, and wise at this point, I think.

> > 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.
>
> What about the L2 network for each segment?
>
What about it?  There may be an L2 network per port and no more.  True in
both my case and Neil's, in fact, where your network system proposed is
just storing address ranges and they're not really L2 segments at all.
(Also, your terminology usage is now getting confusing. ;)

My point is not that your model is *wrong* - it's that it's *not generally
applicable* and therefore shouldn't be encoded in core Neutron as if it's
the only way this could possibly work.  Better that we have a system where
that model is *not* core, and as an added bonus doesn't attempt to make use
of core objects like networks for things that they don't entirely suit.

> I suggested creating provider networks for these.  Do you have a different
> suggestion?
>
My suggestion is per above - that using Neutron 'networks' to be 'a network
to which I can attach a VM' and 'a location specific addressing construct'
is overloading it considerably, and doesn't suit the general purpose case.
And that pluggable IPAM, kinda, allows you to make IPAM specific addressing
models (which are generally admin-only anyway) - or, better, letting the
IPAM system discover for itself how addressing works - is a nicer option.
It's actually not difficult to create completely objects to represent this,
what is difficult is getting that agreed as a change to a core datamodel,
so I think taking this and riffing on it works better than saying 'this is
how it shall be' with a somewhat limited solution.  People can still use
the solutions in the meantime, particularly since they're admin-facing
interfaces.

You know, there comes a moment where I really want to get in front of a
whiteboard...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150721/94cd272a/attachment.html>