Open Stack

It seems to me that offering the choice of a network might be similar to offering the choice of hypervisor. What I mean is that, in our experience, we cannot let the user of the API choose the network because we need to be able to apply more complex policies on top of the selection process (more complex than project/public). It's fine to be able to request for a network through an indirect way, but passing the UUID is really leaving no room for higher level selection logic.
One of the use case I have in mind is where you have a defined capacity for a network. Letting a user select the network explicitly will lead to oversubscription or rejection of the request. What would be better is to allow the user to request a network through a logical label (e.g. "my network", "public network", "internet"), or through some constraints,  and let the logic in quantum, or in the quantum plugins run a process similar to the Nova scheduling process.
The scheduling process can then go through the available networks satisfying the user's request, and return the uuid.
Explicit ordering can still be preserved if a priority is assigned with the requested network label.

JC.


From: "Sumit Naiksatam (snaiksat)" <snaiksat at cisco.com<mailto:snaiksat at cisco.com>>
Reply-To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tue, 28 Aug 2012 01:37:34 +0000
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Quantum] Nova and virtual NICs

I agree with Salvatore and Ian here. The current default behavior seems a little confusing. However, if it’s too late in the cycle to the change the default behavior, we can probably stick with it for now, and change it in G to return an error if no networks are specified.

~Sumit.

From: Salvatore Orlando [mailto:sorlando at nicira.com]
Sent: Monday, August 27, 2012 5:22 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Quantum] Nova and virtual NICs

In my opinion, we should ask ourselves how important it is than in the transition from nova-network to quantum the same behaviour concerning the default nic selection is preserved.
If this turns out to be important, then Quantum should just keep doing what nova-network does at the moment if no --nic option is specified.
Otherwise, the best option for me is, as Ian suggests, to make the --nic compulsory, and return a 400 is no network is specified at all.

Salvatore
On 28 August 2012 01:57, Ian Wells <ijw.ubuntu at cack.org.uk<mailto:ijw.ubuntu at cack.org.uk>> wrote:
On 27 August 2012 19:42, Dan Wendlandt <dan at nicira.com<mailto:dan at nicira.com>> wrote:
> Here's one possible approach: the cloud operator can specify an
> ordered list of network-ids as part of Nova config.  A VM with no
> networks specified via the API will get that ordered set of NICs.  If no such
> networks are specified in the config, we could either give VMs no NICs
> (probably not a great user experience) or default to giving a VM a NIC
> on each shared network (would need a way to deterministically order
> these shared networks for this to be reasonable).
Quite honestly (and inviting contention) - if you're changing the
default 'nothing specified' behaviour from one thing to another, I'd
just go the whole hog and make it an error not to specify any networks
at all.  No default is sensible in all circumstances and what you're
describing is really quite complex.

--
Ian.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________ OpenStack-dev mailing list OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev