Open Stack

> 
> On Sep 8, 2016, at 3:11 PM, Sean Dague <sean at dague.net> wrote:
> 
> On 09/08/2016 09:04 AM, Andrew Laski wrote:
>> 
>> 
>> On Thu, Sep 8, 2016, at 07:18 AM, Sean Dague wrote:
>>> On 09/07/2016 07:34 PM, Andrew Laski wrote:
>>>> 
>>>> 
>>>> On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote:
>>>>> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote:
>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__git-2Dscm.com_book_en_v2_Git-2DInternals-2DPlumbing-2Dand-2DPorcelain&d=CwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=NWKhA-J2KIQGEiKTb4wFudlx1am5gBxyHPlNT1SsaLk&s=gPL9-f0Ias_WpPgP27BaMtNJszadrz57swhz6bBDoQY&e= )
>>>> 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.
>>> 
>>> Personally, I think that the role of Nova is to give you a functional
>>> compute unit. If you can't talk to that over the network, that doesn't
>>> seem very functional to me. For complicated setups it's fine that you
>>> need to do complicated things, but "I would like a working server with
>>> network" doesn't feel like it's a complicated ask from the user.
>> 
>> I'd really like to agree here, however it seems that it is actually a
>> somewhat complicated ask from the user due to the diverse network setups
>> used in practice.
>> 
>> But I was responding to the idea of booting an instance with a
>> floating-ip which to me goes beyond setting up a simple default network
>> for an instance. And I think therein lies the problem, there seems to be
>> some disagreement as to what a simple default network setup should be.
> 
> I agree that floating-ip auto allocation may be over that line, as
> floating ips are specifically constructs that are designed to not be
> tied to servers for the lifecycle of the server. Their value comes in
> having the floating ip last longer than the server.
> 
> But, there is also something here about wanting to make sure you have
> publicly accessable servers (which don't require floating ips specifically).
> 

/me chimes in late because still unearthing from a lot of work travel

Just to piggyback on a lot of what’s been said here, I completely agree that getting external connectivity to an instance is tricky today due to the variety of networking models in use.  That that’s both a strength (in that we have a rich enough platform to accommodate lots of different models to suit lots of different use cases) and a weakness (in that we end up having conversations like this and don’t have an interoperable way for users of multiple clouds to get external connectivity).  As a matter of fact, this very issue was recently mentioned to the Board as one of the top interoperability issues that the DefCore Committee sees in the wild today:

https://github.com/openstack/defcore/blob/master/doc/source/periodic_reports/fall_2016.rst#issue-3-external-network-connectivity

For what it’s worth, the DefCore Committee debated adding floating IP’s to the interoperability Guidelines that products have to follow in order to use the OpenStack name/trademark last fall, and ended up rejecting the idea—mostly for the reasons listed in this thread (e.g. there are a lot of other models and a lot of clouds don’t actually use floating IP’s so they actually aren’t interoperable, etc).

Also worth pointing out: the idea of having an administrative setting to auto-boot instances with a publicly accessible IP (whether that’s on a provider network or whether instances are auto-allocated a floating IP or whatever) is possibly less than ideal from an interoperability point of view, because end users tend to not have good ways of discovering administratively-set config settings.  At a minimum we'd want users to able to programmatically discover which position that knob was set to.

> There seems to be a space about sane default networking for users.
> Get-me-a-network worked through part of it. There might be a good follow
> on for some more standard models of "I really want internet accessible
> system". Neutron is not limited to granting this via floating ips like
> Nova Net was.

+1.  Get-me-a-network made it easier to get an instance booted up and attached to “a" network while alleviating part of the complexity (e.g. various underlying network models) of doing so.  What DefCore is seeing from an interoperability perspective is that get-me-a-network helps fill one need, but there’s still a need for “get-me-an-Internet”.  This is one of those things that a ton of applications running in clouds need, so not having simpler ways to set it up because a real problem for interoperability between OpenStack clouds.  Monty has pointed out all the code in Shade for handling this, which is awesome…but at the end of the day people use a lot of other tools besides Shade to do things in their clouds, and we really don’t want to make all the other tools out there implement similar gobs of logic.  

For what it’s worth, as we’ve talked about this issue with various folks, it seems like the most common thing I hear from people boils down to two asks:

1.) Implement some sort of API that allows an end user to discover what he has to do in order to get external connectivity to an instance.  That might return something that says “do nothing, the IP you got when you booted up is externally reachable”, or “please call this API to get a floating IP”, or “please attach yourself to this particular network which is externally exposed”, or “please start this security scan workflow”, or a plain-English “please leave an envelope containing $500 in small unmarked bills under Joe Root’s keyboard”, or even “sorry, you’re administratively prohibited from having external connectivity”.  

2.)  Implement some kind of get-me-an-Internet API that basically calls #1 and then takes the appropriate action.  Having this separate from #1 allows users to get some info on what they need to do even for cases where #2 will never work because OpenStack itself may not actually be capable of getting you an Internet.  E.g. maybe your organization requires you to fill out a ticket and have it signed in triplicate, sent in, sent back, queried, lost, found, subjected to public inquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters before they’ll flip a bit somewhere to expose your instance to the Internet. [1]  From an interoperability perspective, #1 feels like a thing almost any cloud could be asked to support even if #2 isn’t (and having information is more useful than having none).

This is a bit of a tricky space partly because there are a lot of components touched here, but get-me-a-network feels like it sets the right general direction.  In some cases getting on the Internet may feel like an orchestration task (and as noted in the get-me-a-network specs themselves, there’s been some reluctance to get Neutron into that business).  At the same time it’s *such* a common use case that users seem to want it to be a thing that OpenStack “just handles internally” and minimizes what’s required of end users whenever it can. 

[1] Because you work for Vogons. https://en.wikipedia.org/wiki/Vogon#Appearance_and_personality

At Your Service,
 
Mark T. Voelker



> 
> 	-Sean
> 
> -- 
> Sean Dague
> https://urldefense.proofpoint.com/v2/url?u=http-3A__dague.net&d=CwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=NWKhA-J2KIQGEiKTb4wFudlx1am5gBxyHPlNT1SsaLk&s=AqumAr-B7uiBqpNSHw1zQQolLCCzOCQeIe0VTcRODQU&e= 
> 
> __________________________________________________________________________
> 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