Open Stack

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 <adriant at 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 [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
>
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160908/da4add40/attachment.html>