[openstack-dev] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

Mike Spreitzer mspreitz at us.ibm.com
Mon Sep 28 14:28:52 UTC 2015


> From: Monty Taylor <monty at inaugust.com>
> To: Sylvain Bauza <sbauza at redhat.com>, "OpenStack Development 
> Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>
> Date: 09/28/2015 09:54 AM
> Subject: Re: [openstack-dev] Compute API (Was Re: [nova][cinder] how
> to handle AZ bug 1496235?)
>
> ...
> Specifically, I want "nova boot" to get me a VM with an IP address. I 
> don't want it to do fancy orchestration - I want it to not need fancy 
> orchestration, because needing fancy orchestration to get a VM  on a 
> network is not a feature.
> 
> I also VERY MUCH do not want to need Heat to get a VM. I want to use 
> Heat to do something complex. Getting a VM is not complex. It should not 

> be complex. What it's complex and to the level of needing Heat, we've 
> failed somewhere else.
> 
> Also, people should stop deploying clouds that require people to use 
> floating IPs to get basic internet access. It's a misuse of the 
construct.
> 
> Public Network "ext-net" -> shared / directly attachable
> Per-tenant Network "private" -> private network, not shared, not 
routable
> 
> If the user chooses, a router can be added with gateway set to ext-net.
> 
> This way:
> 
> nova boot --network=ext-net  -> vm dhcp'd on the public network
> nova boot --network=private  -> vm dhcp'd on the private network
> nova floating-ip-attach      -> vm gets a floating ip attached to their 
> vm from the ext-net network
> 
> All of the use cases are handled, basic things are easy (boot a vm on 
> the network works in one step) and for the 5% of cases where a floating 
> IP is actually needed (a long-lived service on a single vm that wants to 

> keep the IP and not just a DNS name across VM migrations and isn't using 

> a load-balancer) can use that.
> 
> This is, btw, the most common public cloud deployment model.
> 
> Let's stop making things harder than they need to be and serve our 
users.

As an operator, +1

Mike



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150928/a0d6f8f2/attachment.html>


More information about the OpenStack-dev mailing list