[openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

Fox, Kevin M Kevin.Fox at pnnl.gov
Wed Sep 7 17:29:52 UTC 2016


Right.

I use floating ip's because I need the flexibility to have an ip out last the vm its attached to.

auto floating ip's are in the "just put this on the network, I don't care what happens when I need to delete my vm" kind of thing. which just having public ip's also could also solve.

Thanks,
Kevin
________________________________________
From: Monty Taylor [mordred at inaugust.com]
Sent: Wednesday, September 07, 2016 10:00 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 11:27 AM, Fox, Kevin M wrote:
> 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.

Yes.

I'd categorize the main things possible as:

"I want a VM on a public network"
"I want a VM on a private network"
"I want a VM on both a public and private network"

For both instances of "public network" - there are:

"I want a public IP and do not care how that happens"
"I specifically want a floating IP"
"I specifically want a non-floating IP"

I'd argue though that the on the clouds where you have the option of a
direct attached public IP and also of getting a floating IP, the people
from the:

"I want a VM on both a public and private network"

camp who explicitly want a floating and not a fixed public IP are users
whom a "give me an auto public ip" feature is likely not going to serve
without making that feature too complex. It is already completely
possible for a user to create a server without an auto function, and
then to select a floating ip if that is a construct they desire.

With using an auto function, the user is effectively saying:

"I want a public IP and do not care how that happens"

which is the use case that is not possible today unless you happen to be
a shade user.

> ________________________________________
> 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
>
> __________________________________________________________________________
> 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
>


__________________________________________________________________________
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



More information about the OpenStack-dev mailing list