Open Stack

On Fri, Nov 6, 2015 at 2:59 PM, Shraddha Pandhe <spandhe.openstack at gmail.com
> wrote:
>
> We have a similar requirement where we want to pick a network thats
> accessible in the rack that VM belongs to. We have L3 Top-of-rack, so the
> network is confined to the rack. Right now, we are achieving this by naming
> physical network name in a certain way, but thats not going to scale.
>
> We also want to be able to make scheduling decisions based on IP
> availability. So we need to know rack <-> network <-> mapping.  We can't
> embed all factors in a name. It will be impossible to make scheduling
> decisions by parsing name and comparing. GoDaddy has also been doing
> something similar [1], [2].
>

This is precisely the use case that the large deployers team (LDT) has
brought to Neutron [1].  In fact, GoDaddy has been at the forefront of that
request.  We've had discussions about this since just after Vancouver on
the ML.  I've put up several specs to address it [2] and I'm working
another revision of it.  My take on it is that Neutron needs a model for a
layer 3 network (IpNetwork) which would group the rack networks.  The
IpNetwork would be visible to the end user and there will be a network <->
host mapping.  I am still aiming to have working code for this in Mitaka.
I discussed this with the LDT in Tokyo and they seemed to agree.  We had a
session on this in the Neutron design track [3][4] though that discussion
didn't produce anything actionable.

Solving this problem at the IPAM level has come up in discussion but I
don't have any references for that.  It is something that I'm still
considering but I haven't worked out all of the details for how this can
work in a portable way.  Could you describe how you imagine how this flow
would work from a user's perspective?  Specifically, when a user wants to
boot a VM, what precise API calls would be made to achieve this on your
network and how where would the IPAM data come in to play?

Carl

[1] https://bugs.launchpad.net/neutron/+bug/1458890
[2] https://review.openstack.org/#/c/225384/
[3] https://etherpad.openstack.org/p/mitaka-neutron-next-network-model
[4] https://www.openstack.org/summit/tokyo-2015/schedule/design-summit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151109/3265002d/attachment.html>