Open Stack

On 30 August 2012 22:38, Blake Yeager <blake.yeager at gmail.com> wrote:

> On Tue, Aug 28, 2012 at 3:52 PM, Dan Wendlandt <dan at nicira.com> wrote:
>
>> On Tue, Aug 28, 2012 at 1:30 PM, Ian Wells <ijw.ubuntu at cack.org.uk>
>> wrote:
>>
>  > On 28 August 2012 22:08, 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.
>> >
>> > 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120831/038f60c7/attachment.html>