On Fri, Nov 6, 2015 at 2:59 PM, Shraddha Pandhe <[email protected] > 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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
