Double api sounds a little terrifying when really there are probably so many different ways you can already solve this using the services we already have.
The thing I don't get is Martin's requirement that "an instance must have internet on boot" and that to do that he must have a floating ip assigned to it. Internet on boot I can understand because of preconfigured images and snapshots starting internal services and tasks on boot, but why is floating ip on boot such a hard requirement? Is adding a floating ip before boot even possible with Nova right now (I ask as I've never looked into it)? Unless I'm missing something, you can easily setup a private network with internet access, boot your instance on that, and then add a floating ip. The instance will have internet on boot, and then be given a floating ip. Does that not solve your problem and can that not be orchestrated with the current range of services/tools we have? On 08/09/16 12:41, 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? > > 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
