[openstack-dev] [Quantum] Nova and virtual NICs

Dan Wendlandt dan at nicira.com
Tue Aug 28 20:08:33 UTC 2012


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
~~~~~~~~~~~~~~~~~~~~~~~~~~~



More information about the OpenStack-dev mailing list