Open Stack

On 2013/27/11 00:00, Robert Collins wrote:
> On 26 November 2013 07:41, Jaromir Coufal <jcoufal at redhat.com> wrote:
>> Hey Rob,
>>
>> can we add 'Slick Overcloud deployment through the UI' to the list? There
>> was no session about that, but we discussed it afterwords and agreed that it
>> is high priority for Icehouse as well.
>>
>> I just want to keep it on the list, so we are aware of that.
> Certainly. Please add a blueprint for that and I'll mark itup appropriately.
I will do.

> Related to that we had a long chat in IRC that I was to follow up here, so - ...
>
> Tuskar is refocusing on getting the basics really right - slick basic
> install, and then work up. At the same time, just about every nova
> person I've spoken too (a /huge/ sample of three, but meh :)) has
> expressed horror that Tuskar is doing it's own scheduling, and
> confusion about the need to manage flavors in such detail.
> So the discussion on IRC was about getting back to basics - a clean
> core design and something that we aren't left with technical debt that
> we need to eliminate in order to move forward - which the scheduler
> stuff would be.
>
> So: my question/proposal was this: lets set a couple of MVPs.
>
> 0: slick install homogeneous nodes:
>   - ask about nodes and register them with nova baremetal / Ironic (can
> use those APIs directly)
>   - apply some very simple heuristics to turn that into a cloud:
>     - 1 machine - all in one
>     - 2 machines - separate hypervisor and the rest
>     - 3 machines - two hypervisors and the rest
>     - 4 machines - two hypervisors, HA the rest
>     - 5 + scale out hypervisors
>   - so total forms needed = 1 gather hw details
>   - internals: heat template with one machine flavor used
>
> 1: add support for heterogeneous nodes:
>   - for each service (storage compute etc) supply a list of flavors
> we're willing to have that run on
>   - pass that into the heat template
>   - teach heat to deal with flavor specific resource exhaustion by
> asking for a different flavor (or perhaps have nova accept multiple
> flavors and 'choose one that works'): details to be discussed with
> heat // nova at the right time.
>
> 2: add support for anti-affinity for HA setups:
>   - here we get into the question about short term deliverables vs long
> term desire, but at least we'll have a polished installer already.
>
> -Rob

Important point here is, that we agree on starting with very basics - 
grow then. Which is great.

The whole deployment workflow (not just UI) is all about user experience 
which is built on top of TripleO's approach. Here I see two important 
factors:
- There are *users* who are having some *needs and expectations*.
- There is underlying *concept of TripleO*, which we are using for 
*implementing* features which are satisfying those needs.

We are circling around and trying to approach the problem from wrong end 
- which is implementation point of view (how to avoid own scheduling).

Let's try get out of the box and start with thinking about our audience 
first - what they expect, what they need. Then we go back, put our 
implementation thinking hat on and find out how we are going to re-use 
OpenStack components to achieve our goals. In the end we have detailed plan.


=== Users ===

I would like to start with our targeted audience first - without 
milestones, without implementation details.

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

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.


=== Milestones ===

Based on different user behavior I am talking about, I suggest different 
milestones:

V0: basic slick installer - flexibility and control first
- enable user to auto-discover (or manual register) nodes
- let user decide, which node is going to be controller, which is going 
to be compute or storage
- associate images with these nodes
- deploy

V1: monitoring and support for node profiles
- monitor the deployment, services and nodes
- allow user to define 'node profiles' (which are helping with 
suggestions where the node belongs, but user always has to have control 
on that)
- give user smart guidance where the hardware belongs

V2: advanced settings
- give possibility to choose which services are going where (at the 
moment he would have all controller services at one node).
- enhance networking setup

V?: grow, add functionality
- more views on infrastructure (network, physical reality - racking, etc).
- more monitoring
- more possibilities of various stuff management
- scheduled maintenance
- smart power consumption
- ...?


=== 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.

More details should follow here - how to achieve above mentioned goals, 
like what should go through heat, what should go through nova, ironic, etc.

But first, let's agree on approach and goals.

-- Jarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131127/59d23758/attachment.html>