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

JC Martin jcmartin at ebaysf.com
Tue Sep 18 18:35:33 UTC 2012


Salvatore,

I saw this mail a bit late, and let me start by saying that I support the decision to stay with the current behavior for the Folsom release. However, I would like to explain a bit my point and why I think it's relevant for the thread :

Specifying an ordered list of networks as part of the nova config is not flexible enough because of the points I made, i.e. the necessity to do capacity management.

So, the way we solved this problem is by having a specific scheduler in Nova that is able to inject networks in the case where they are not specified by a user. The selection is based on the number of IP addresses available on that network, and could include other logic. If multiple networks need to be injected, the order specified during network creation is preserved unless there is a conflict.

The next step would be, if we have generic uuid for networks, and if the user is specifying one of those during instance creation, to resolve these generic uuid into specific networks, again, based on capacity or additional logic.

JC

From: Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.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: Fri, 31 Aug 2012 19:31:10 +0200
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



On 30 August 2012 22:38, Blake Yeager <blake.yeager at gmail.com<mailto:blake.yeager at gmail.com>> wrote:
On Tue, Aug 28, 2012 at 3:52 PM, Dan Wendlandt <dan at nicira.com<mailto:dan at nicira.com>> wrote:
On Tue, Aug 28, 2012 at 1:30 PM, Ian Wells <ijw.ubuntu at cack.org.uk<mailto:ijw.ubuntu at cack.org.uk>> wrote:
> On 28 August 2012 22:08, Dan Wendlandt <dan at nicira.com<mailto: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.
>
> I appreciate your point.  A reasonable compromise would be that if a
> tenant truly has only one network available, boot; if there's more or
> less than one, don't boot.

I think this is a reasonable design point.

This covers your case above, doesn't have
> complex 'choosing networks' behaviour, and doesn't default to 'one NIC
> per network' behaviour which is almost never what you want to happen
> when you start a machine

I wouldn't say "almost never", as I've actually had several customers
who had a default setups where VMs had two NICs (one public, one
back-end private).  In fact, the reason nova worked this way in the
first place was because a very large and early contributor has a
public cloud that works that way today, with two NICs per VM.

Changing this behavior would, I think, break things for such
deployments, though I think its a pretty nice point in the design
space and one I'm more comfortable with than the 400 approach.  To me
it fits the 'simple is simple, complex is more complex' motto :)


My apologies for jumping on the thread late but I think we are missing a key point that was part of Dan's original proposal which was that a cloud operator could specify an ordered list of network-ids as part of Nova config.  This would allow you to expand the design to say that if no network is specified at VM creation you first check if there are network-ids included in Nova config.  If there are then you simply create the VM with a NIC on each network listed in Nova config.  If not then you check if the tenant has one and only one network available to him.  If that is the case then you create the VM with a NIC on that network.  If the tenant has more or less than one network available then you return a 400 error.  These seems to be the best of both worlds to me, allowing cloud operators to provide a consistent experience to their users while maintaining the necessary flexibility.

This is an option that we are surely considering; I don't think we dismissed it; while this might satisfy a wide range of use cases it does not fit the case where instance are launched with 1 shared and 1 private NIC.

We also agreed that radically changing the agree behavior is a no go, and not just because it would "surprise" users transitioning from nova-network to quantum. We received feedback that actually there are a use cases where the networks are not specified at all.

Considering other contributions to this thread, I reckon the introduction of 'network flavors' in nova, or extending the current concept of flavor to support networks. Those flavors might be used with both nova-network and quantum, and could be 'generic' (ie: applicable to any tenant) or tenant-specific. If my memory does not fail me, there's already been discussion in nova on this topic. Other IaaS systems (open source and not) have similar templating mechanisms which extend to networking resources.

Nevertheless, unless there's a huge push in this direction, for the Folsom release I would either stay with the current approach, or adopt the order list of networks, which in my opinion is a good stopgap measure.

If I interpret JC Martin's words correctly, his point does not directly apply to this thread; nevertheless optimized scheduling for efficient network resource management is another important topic that we should tackle both in Nova and Quantum.

Salvatore



-Blake


_______________________________________________
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



More information about the OpenStack-dev mailing list