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

Martin Millnert martin at millnert.se
Wed Sep 7 08:31:16 UTC 2016


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.

> >   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.

> 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".

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".

> > 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.

Best regards,
Martin



More information about the OpenStack-dev mailing list