Open Stack

We have the same issue in an OpenStack deployment that I'm working with where developers don't usually specify a network, and we have to allocate one based on factors like available networks and capacity. The default behavior does not work in this case. 

I'm new to Quantum codebase, and wondering if there a way plugin some logic to customize network selection.

Thanks for any pointers.
Subbu 

On Aug 28, 2012, at 1:08 PM, Dan Wendlandt <dan at nicira.com> wrote:

> Giving the tenant a 400 is a clean response from a design perspective,
> but it worries me, as my sense is that people have gotten used to
> spinning up nova VMs without specifying networks.  In particular, it
> makes a shift to quantum from nova-network necessarily a
> tenant-visible event (i.e., tenant scripts break), even for tenants
> only using functionality that was available with nova-network. The
> existing policy was designed to be backward compatible with the Nova
> model for that reason.
> 
> A related concern I have is that a cloud deployment may want to offer
> advanced networking to a subset of its customers, while using simple
> flat networking for others.  The 400 approach forces all users of the
> cloud to specify network connectivity whenever they boot a VM, even if
> they only have one possible network they will ever access (one could
> argue that this could be handled with better client tools which check
> if only one network is available and use it, but there's still
> complexity there).
> 
> So I guess in that sense, I agree with Salvatore's comment that if
> transition is important, we should keep the model as is.  It seems to
> fit the general rule that the simple case should be simple, and doing
> something more complex is a bit more complex.
> 
> Dan
> 
> 
> On Tue, Aug 28, 2012 at 9:11 AM, Edgar Magana (eperdomo)
> <eperdomo at cisco.com> wrote:
>> + 1  (Salvatore and Sumit)
>> 
>> 
>> 
>> Edgar
>> 
>> 
>> 
>> From: Sumit Naiksatam (snaiksat)
>> Sent: Monday, August 27, 2012 6:38 PM
>> 
>> 
>> To: OpenStack Development Mailing List
>> 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> wrote:
>> 
>> On 27 August 2012 19:42, Dan Wendlandt <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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev