On 03/02/2016 01:04 PM, Xav Paice wrote:
On 3 March 2016 at 07:52, Sean Dague <[email protected]
<mailto:[email protected]>> 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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
