<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 6, 2015 at 2:59 PM, Shraddha Pandhe <span dir="ltr"><<a href="mailto:spandhe.openstack@gmail.com" target="_blank">spandhe.openstack@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div><div>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].</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Carl </div><div><br></div><div>[1] <a href="https://bugs.launchpad.net/neutron/+bug/1458890">https://bugs.launchpad.net/neutron/+bug/1458890</a></div><div>[2] <a href="https://review.openstack.org/#/c/225384/">https://review.openstack.org/#/c/225384/</a></div><div>[3] <a href="https://etherpad.openstack.org/p/mitaka-neutron-next-network-model">https://etherpad.openstack.org/p/mitaka-neutron-next-network-model</a></div><div>[4] <a href="https://www.openstack.org/summit/tokyo-2015/schedule/design-summit">https://www.openstack.org/summit/tokyo-2015/schedule/design-summit</a></div></div></div></div>