Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev