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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev