Why don't you just pre-create the port and associate the floating IP before booting the instance?
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
