----- Original Message ----- > > On 2013/27/11 00:00, Robert Collins wrote: > > > > On 26 November 2013 07:41, Jaromir Coufal <[email protected]> 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 > [email protected] > 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
