Open Stack

----- Original Message -----
> 
> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

It seems to me that both approaches are trying to get to the same place - options for both "smart" node handling and manual control.

Would it make more sense to agree that those are both important goals, come up with a design, and then see what direction it makes sense
to start with?  I don't think the specific contents of v0 are as important as making sure we have a foundation that supports the ultimate
goal, along with a clear design and roadmap that shows how we will get there.


Mainn