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

Andrew Laski andrew at lascii.com
Thu Sep 8 13:12:05 UTC 2016



On Wed, Sep 7, 2016, at 08:41 PM, Fox, Kevin M wrote:
> Interesting. It kind of sounds like your proposing a sort of... openstack
> standard library api api? (yes, double apis) Where you can build up an
> api using other api calls and users can rely on those standard
> overarching api's to be there?

What I was thinking was just a service that can interact with multiple
projects for simple API requests. If we take the example from elsewhere
in this thread of pre-creating a port, assigning a floating-ip to it,
and then booting an instance with that port that's currently multiple
calls to two different services. I would love to see a service that can
take all of that info in one request and then make the multiple calls
necessary on behalf of the user. I additionally would expect it to be
able to list resources, delete resources, whatever the user needs.

My grand idea would be that users do not interact with
Nova/Cinder/Neutron directly unless they have specific complex needs and
instead use a new API proxy/orchestration service. For a long time it's
been said that this should be handled for a user on the client side.
That works great for users who wish to use a client that does that, but
there are many users out there who do not use something like
openstackclient, for various reasons.

> 
> Thanks,
> Kevin
> ________________________________________
> From: Andrew Laski [andrew at lascii.com]
> Sent: Wednesday, September 07, 2016 4:34 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch
> instance with Floating IP
> 
> On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote:
> > On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote:
> > > This is exactly what something like Minstral would be fantastic for.
> > > Multi-project workflow.
> > > Rather than try and build logic like this directly into nova, looks
> > > at extending something like Minstral with a basic easy to call task.
> >
> > I have API- and code-reading homework to do here - but based on input
> > on IRC, and efforts thus far, the ideal solution is not really to bolt
> > a humongous piece of logic onto Nova. Rather it is appears to be first
> > and foremost Neutron that need a little bit more intelligence regarding
> > its virtual networks and the intentions of its operators.
> >
> > From what I can tell, Mistral is a very useful project for scheduling
> > recurring tasks or similar, which there is a definite need of in a
> > mature deployment.
> >
> > But I disagree with the "solve it with a new project"-approach here:
> >
> >  1) "launch my instance" is as core as it gets in OpenStack,
> >
> >  2) "launch my instance with Internet" is approximately identically as
> > core, just a bit difficult for $reasons and not fully supported today,
> >
> >  3) core functionality should IMO require as few API calls as possible,
> > to as few components as possible, while keeping REST data models etc.
> > intact, [1][2]
> 
> I agree that it should require as few API calls as possible but maybe we
> disagree about what core functionality is. Or to put it another way,
> what is core functionality depends on your perspective.
> 
> I subscribe to the plumbing and porcelain approach
> (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain)
> and believe that Nova should be part of the plumbing. So while I fully
> agree with a small number of API calls to do simple tasks I don't
> believe that orchestrating network setups is core functionality in Nova
> but is core to OpenStack.
> 
> >
> >  4) there are timing concerns with adding Internet to an instance today
> > in OpenStack, since it in some cases needs to happen somewhere between
> > the events "network port created" and "instance launched", in order for
> > the instance to actually have Internet when it boots,
> >
> >  5) Scheduling "Launch instance with Internet" or "Add Internet to
> > instance" via something like Mistral would additionally either, A) add
> > a significant delay to the boot time, or B) not even fulfill the
> > objective of having Internet once instance powers on,
> >
> >  6) To replicate the logic of shade's "get me online" functions, a
> > large amount of code is required, and depending on how you go about it,
> > you also risk duplicating logic already in e.g. Nova or Neutron.
> >
> > Best regards,
> > Martin
> >
> > [1] "A designer knows he has achieved perfection not when there is
> > nothing left to add, but when there is nothing left to take away."
> >   -- Antoine de Saint-Exupery
> > [2] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community
> > -02.txt (example of commendable improvement almost unheard of within
> > the IETF)
> >
> > __________________________________________________________________________
> > 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
> 
> __________________________________________________________________________
> 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
> 
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list