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 [and...@lascii.com] > Sent: Wednesday, September 07, 2016 4:34 PM > To: openstack-dev@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-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 > > __________________________________________________________________________ > 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