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 [[email protected]] Sent: Wednesday, September 07, 2016 10:00 AM To: [email protected] 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 [[email protected]] > Sent: Wednesday, September 07, 2016 8:55 AM > To: [email protected] > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
