On Thu, Sep 8, 2016, at 05:48 AM, Kevin Benton wrote: > Why don't you just pre-create the port and associate the floating IP > before booting the instance? Right. It's not difficult to do at all but there's a strong desire to have this be encompassed in a single API call. I think that's a great idea, but I don't think it belongs in Nova. > > On Wed, Sep 7, 2016 at 5:58 PM, Adrian Turjak > <adri...@catalyst.net.nz> wrote: >> 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 > ____________________________________________________________________- > ________ > 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