<br><br><div class="gmail_quote">On 30 August 2012 22:38, Blake Yeager <span dir="ltr"><<a href="mailto:blake.yeager@gmail.com" target="_blank">blake.yeager@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Aug 28, 2012 at 3:52 PM, Dan Wendlandt <span dir="ltr"><<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>></span> wrote:</div><div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Tue, Aug 28, 2012 at 1:30 PM, Ian Wells <<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>> wrote:</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
> On 28 August 2012 22:08, Dan Wendlandt <<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>> wrote:<br>
>> Giving the tenant a 400 is a clean response from a design perspective,<br>
>> but it worries me, as my sense is that people have gotten used to<br>
>> spinning up nova VMs without specifying networks.<br>
><br>
> I appreciate your point. A reasonable compromise would be that if a<br>
> tenant truly has only one network available, boot; if there's more or<br>
> less than one, don't boot.<br>
<br>
</div>I think this is a reasonable design point.<br>
<div><br>
This covers your case above, doesn't have<br>
> complex 'choosing networks' behaviour, and doesn't default to 'one NIC<br>
> per network' behaviour which is almost never what you want to happen<br>
> when you start a machine<br>
<br>
</div>I wouldn't say "almost never", as I've actually had several customers<br>
who had a default setups where VMs had two NICs (one public, one<br>
back-end private). In fact, the reason nova worked this way in the<br>
first place was because a very large and early contributor has a<br>
public cloud that works that way today, with two NICs per VM.<br>
<br>
Changing this behavior would, I think, break things for such<br>
deployments, though I think its a pretty nice point in the design<br>
space and one I'm more comfortable with than the 400 approach. To me<br>
it fits the 'simple is simple, complex is more complex' motto :)<br>
<span><font color="#888888"><br></font></span></blockquote><div><br></div></div><div>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.</div>
</div></div></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Salvatore</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div>
-Blake</div></font></span></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br>