Open Stack

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
> <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
> ____________________________________________________________________-
> ________
> 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/5485929c/attachment.html>