Open Stack

Hi Adrian,


On Thu, 2016-09-08 at 12:58 +1200, Adrian Turjak 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"

Instances cannot be guaranteed to not require Internet... so it must be
there from scratch, or things like for example Ubuntu's entropy download
for ssh-generation in cloud-init will fail.

>  and that to do that he must have a floating ip
> assigned to it.

That's one of the networking models we have for public IP.

>  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)?

>From what I understand, current calls for assigning floating IP requires
not just the server, but a network port to exist. I assume "server
create" finishes off with "server start".

> 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?

Our private networks are private networks, there is no Internet access
from them without a floating IP, i.e. no source NAT. It's the VPC model.
If our private networks were to, by default, not actually be private
networks, and have source NAT to the Internet, then, yes, that'd solve
that particular problem, at the expense of no longer having private
networks.

Best,
Martin

> 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