Open Stack

On the flip side, so is "I want my vm on a private network and I want a floating ip to attach it to the public network."

As some clouds don't support it.

Thanks,
Kevin
________________________________________
From: Monty Taylor [mordred at inaugust.com]
Sent: Wednesday, September 07, 2016 8:55 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

On 09/07/2016 03:31 AM, Martin Millnert wrote:
> Hi Matt,
>
> On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote:
>> Floating IPs aren't required in OpenStack deployments, and anyone
>> running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use
>> or
>> support them, at least without patching Nova. So I'm not sure what
>> 'industry standard' is being referred to here.
>
> Nod. There are many models, I acknowledge that as well. When referring
> to 'industry standard', I refer to e.g. default EC2 VPC or GCE non-
> legacy network behaviour. I didn't mean to imply that this model is the
> only one, not even the best one, just the most widely used one at
> large.

It's a terrible networking choice. NAT is a terrible model for doing
networking on the Internet. One of the things I'm most proud of about
OpenStack is that we allow people to make clouds that are not inherently
broken like AWS and GCE are.

THAT SAID ....

"I would like to boot a VM that has a public IP"

is a very clear use case, and it's very hard to achieve across OpenStack
clouds. If you want to gouge your eyes out, go read the giant pile of
code in the shade library which implements this.

So - yes please on the feature - although it should be called
"--auto-assign-public-ip" or "--auto-assign-external-ip" or something,
not floating - because part of the problem is actually knowing whether
or not the cloud requires floating ips or doesn't.

However, as I mentioned, it's a GIANT amount of code to get this
'right'. We've gone thought a ton of iterations on it over the last 2
years - I recommend strongly not starting from scratch.

>>>   Problem:
>>>  - nova: we're not adding anything
>>
>> Correct, nova provides the APIs to do this already, something sitting
>> on top just needs to use them to orchestrate your use case.
>
> It exists in terms of multiple calls, yes. My e-mail is about what the
> best multi-project solution to improving the total logic required to
> achieve the goal, within OpenStack. It's not clear the answer is to
> improve Nova's server create API, but it is one very obvious candidate
> solution.

It would be the nicest thing, but it would also require nova to learn a
lot more about neutron than it currently needs to know.

>> The get-me-a-network work is complete with the 2.37 API microversion
>> in Nova and the 6.0.0 python-novaclient release. You can test it out
>> today.
>> However, it does not allocate and auto-assign a floating IP.
>
> I'd argue that what a typical user is most interested in is not, in
> fact, in "having a network", but, "having internet access".

Yes, this is correct.

> Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one
> of them, as you point out, deals with auto-allocating-and-assigning
> FIPs, which is fine in and of itself - Rome wasn't built in one day
> either.
>
> I.e. today,
>  A) 'networks=auto' != "get me online",
>  B) 'networks=auto' == "get me an openstack network interface".
>
> B is a subset of A, but A is not a subset of B.
>
> Assuming,
>  1) 'networks' is definitely meant to mean just what it's called, and does today, and
>  2) "get me online" is a desirable feature,
>
> then it is actually the case that we're missing an option like "public_ip=auto" or similar to complete the picture.
> In the deployments you mention above, it'd have virtually nothing to do. In others, for example FIP, it'd have only little to do.
>
> Then, the combination networks=auto, public_ip(v4)=auto would equal "getmeonline".

Yes. This is, in fact, how the shade create_server API works.

>>> So how can one solve an OpenStack cross-project problem like
> this,
>>> possibly without having to implement an artificial
>>> superintelligence
>>> first?
>>
>> Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or
>> maybe even Heat would support this.
>
> Right, the total amount of options are thus:
> 1) Introduce a new, custom API service to proxy for Nova, and fork
> Horizon to handle it,
> 2) Patch Nova and do UI fixes in Horizon, but do not submit it
> upstream,
> 3) Patch Nova and do UI fixes in Horizon, and submit it upstream,
> 4) Make Horizon stateful and do UI changes, but do not submit it
> upstream,
> 5) Make Horizon stateful and do UI changes, and submit it upstream
>
> I'm sure there are more enumerations of this, but Heat is not one of
> them. :-)
>
> To me, from the above, option 3 seems the one that involves the least
> amount of complexity, which already there is a good indication of being
> the right choice.

I think the complexity in 3 should not be understated... but please
don't fork and not submit upstream... :)

Monty

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev