Open Stack

On 03/02/2016 01:04 PM, Xav Paice wrote:
>
>
> On 3 March 2016 at 07:52, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
>
>     On 03/02/2016 01:46 PM, Armando M. wrote:
>     <snip>
>     > IMO, I think that's a loophole that should be closed. We should all
>     > strive to make OpenStack clouds behave alike.
 >
>     It might be a loophole. But it's also data. People are doing that thing
>     for a reason based on customer feedback. If the general norms are that
>     this is allowed, and OpenStack clouds do the opposite, they will be
>     considered broken compared to the norms.
>
>
> Not the customers I've spoken with.
>
> I'm OK with doing something different to RAX, in fact some people might
> consider RAX to be broken when they see it different from us.  I'm not
> keen on any cloud being considered 'broken' because of an implementation
> detail, and every cloud has some level of differences.  Just take a look
> at os_client_config to see some of the differences (and the ways to make
> that easier).

++ to looking at os_client_config :)

I do a bad job of trying to communicate this every time, but I'm going 
to try one more time ...

What I really want out of OpenStack clouds is this:

- A 'public' or 'northbound' network that I can choose to boot my 
computer on. If I choose to boot my computer on this network, I will get 
directly attached to that network. My computer will be able to know its 
IP address.

- The option to create one or more 'private' networks that I can attach 
my computers to.

- The option to create one or more floating ips that allocate an IP from 
the 'public' or 'northbound' network but associate them with the compute 
of my choice via NAT.

- A default security group that does 'sensible' things like blocking a 
bunch of traffic.

- Either a second default security group that is wide-open or the option 
to opt-out of having a security group associated with my computer at all.

I want all of the OpenStack clouds to do all of those things.

Why?

Because those things encompass the set of use cases that people actually 
use OpenStack for.

If you don't have the ability to direct attach IPs to your computer, 
there are a set of things that either don't work, or that work very 
poorly. If you are running one of those things, you know it, and you 
know what you need. If you are running one of those things, NAT is not a 
feature, it's a bug.

If you don't have floating IPs/NAT, then you do not fit easily into the 
"most of my things on private except I want to poke a little bit of 
public on to one of them" model which is prevelant in the "cloud native" 
thinking.

Amazingly enough, though, OpenStack can actually TODAY support all of 
the above, we just have people who believe that some end users should 
not be allowed to want to run the types of applications in the cloud 
that they want (or need) to run.

There are some problems - most notably UI.

If you have two networks defined in a cloud, you have to specify which 
network you want to boot on - and you have to do this via network id. 
That's very un-user-friendly. There is no way for a user of a cloud ot 
say "hey, I really never want to boot things directly on the public 
network". A user CAN delete a private network that was created for them 
if they don't want it - so that direction is friendly. However, a user 
cannot choose to boot a computer directly on a public network if the 
deployer has not allowed them to.

So we have work to do in our command line and REST API in terms of 
dealing with mutli-networks and expressions of user intent. However, we 
can't even begin that work as long as we persist with the idea that 
there is only one "right" networking model.

I'd really like to see devstack nodes start to boot with a shared public 
AND a private AND floating ips. That way we can both test all of the 
possible combinations in a single cloud, and as developers we can 
experience the pain that exists currently for customers in multi-network 
clouds.

Also, with the security groups - why not have a "default" and an "open" 
security group by default?

And finally- how about some sort of user settable preferneces somewhere? 
And how about the ability to use those to have users opt in to various 
networking schemes on a project-by-project basis? (Because I'm sure we 
all already agree that every customer should get a domain and domain 
admin in that domain and be able to create users and projects to their 
heart's desire since we all love our users)

If we have a cloud with a shared public and optional private networks, 
then it's conceivable that at project creation time a user could say 
"hey, make me a project and let that project see the shared public 
network" - or "hey, make me a project and do not let that project see 
the shared public network" - that way default boot commands in each 
project would attach to the right thing - and only in the honestly quite 
strange situation where you actually want both and want direct routing 
will you need to specify nics to bind ... but you're almost certainly ok 
with that at that point because you've opted in to it as a user.

So - what do you say? Shall we make things better for our users and stop 
trying to second guess their actual desires? I know that would sure make 
me happy!

Monty