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 class="gmail_quote"><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 1:30 PM, Ian Wells <<a href="mailto:ijw.ubuntu@cack.org.uk">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 class="im">
> On 28 August 2012 22:08, Dan Wendlandt <<a href="mailto:dan@nicira.com">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 class="im"><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 class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></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><br></div><div>-Blake</div></div><br></div>