On Wed, Sep 7, 2016, at 04: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. > > > > 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,
I would change this slightly and say that my preference would be to have a new API service which can handle cross project orchestration needs. Things like what you're discussing, or creating a volume and booting from it, and many other things that require a client to touch multiple services. I believe there's a gap here that Heat doesn't fill and that encourages people to think that adding orchestration to Nova is the right thing to do. > 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 __________________________________________________________________________ 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