Open Stack

Hi Jarda,

On Wed, 2013-11-27 at 14:39 +0100, Jaromir Coufal wrote:

> I think here is the main point where I disagree and which leads to 
> different approaches. I don't think, that user of TripleO cares *only* 
> about deploying infrastructure without any knowledge where the things 
> go. This is overcloud user's approach - 'I want VM and I don't care 
> where it runs'. Those are self-service users / cloud users. I know we 
> are OpenStack on OpenStack, but we shouldn't go that far that we expect 
> same behavior from undercloud users.

Nice, I think you're getting really close to identifying the conflicting
assumptions/viewpoints here.

What OpenStack - and cloud, in general - does is provide a nice
self-service abstraction between the owners of the underlying resources
and the end-user.

We take away an awful lot of placement control away from the
self-service in order to allow the operator to provide a usable,
large-scale, multi-tenant service.

The difference with TripleO is that we assume the undercloud operator
and the undercloud user are one and the same. At least, that's what I
assume we're designing for. I don't think we're designing for a
situation where there is an undercloud operator serving the needs of
multiple overcloud operators and it's important for the undercloud
operator to have ultimate control over placement.

That's hardly the end of the story here, but it is one useful
distinction that could justify why this case might be different from the
usual application-deployment-on-IaaS case.

> I can tell you various examples of 
> why the operator will care about where the image goes and what runs on 
> specific node.
> 
> /One quick example:/
> I have three racks of homogenous hardware and I want to design it the 
> way so that I have one control node in each, 3 storage nodes and the 
> rest compute. With that smart deployment, I'll never know what my rack 
> contains in the end. But if I have control over stuff, I can say that 
> this node is controller, those three are storage and those are compute - 
> I am happy from the very beginning.

It is valid to ask why this knowledge is important to the user in this
case and why it makes them happy. Challenging such assumptions can lead
to design breakthroughs, I'm sure you agree.

e.g. before AWS came along, you could imagine someone trying to shoot
down the entire premise of IaaS with similar arguments.

Or the whole "they'd have asked for a faster horse" thing.

> Our targeted audience are sysadmins, operators. They hate 'magics'. They 
> want to have control over things which they are doing. If we put in 
> front of them workflow, where they click one button and they get cloud 
> installed, they will get horrified.
>
> That's why I am very sure and convinced that we need to have ability for 
> user to have control over stuff. What node is having what role. We can 
> be smart, suggest and advice. But not hiding this functionality from 
> user. Otherwise, I am afraid that we can fail.
> 
> Furthermore, if we put lots of restrictions (like homogenous hardware) 
> in front of users from the very beginning, we are discouraging people 
> from using TripleO-UI. We are young project and trying to hit as broad 
> audience as possible. If we do flexible enough approach to get large 
> audience interested, solve their problems, we will get more feedback, we 
> will get early adopters, we will get more contributors, etc.
> 
> First, let's help cloud operator, who is having some nodes and wants to 
> deploy OpenStack on them. He wants to have control which node is 
> controller, which node is compute or storage. Then we can get smarter 
> and guide.

Yes, I buy this. And I think it's the point worth dwelling on.

It would be quite a bit of work to substantiate the point with hard data
- e.g. doing user testing of mockups with and without placement control
- so we have to at least try to build some consensus without that.

We could do some work on a more detailed description of the persona and
their basic goals. This would clear up whether we're designing for the
case where one persona owns the undercloud and there's another overcloud
operator persona.

We could also look at other tools targeted to similar use cases and see
what they do.

But yeah - my instinct is that all of that would show that we'd be
fighting an uphill battle to persuade our users that this type of magic
is what they want.

...
> === Implementation ===
> 
> Above mentioned approach shouldn't lead to reimplementing scheduler. We 
> can still use nova-scheduler, but we can take advantage of extra params 
> (like unique identifier), so that we specify more concretely what goes 
> where.

It's hard to see how what you describe doesn't ultimately mean we
completely by pass the Nova scheduler. Yes, if you request placement on
a specific node, it does still go through the scheduler ... but it
doesn't do any actual scheduling.

Maybe we should separate the discussion/design around control nodes and
resource (i.e. compute/storage) nodes. Mostly because there should be a
large ratio of the latter to the former, so you'd expect it to be less
likely for such fine grained control over resource nodes to be useful.

e.g. maybe adding more compute nodes doesn't involve the user doing any
placement, and we just let the nova scheduler choose from the available
nodes which are suitable for compute workloads.

Mark.