[openstack-dev] [TripleO][Tuskar] Icehouse Requirements

Robert Collins robertc at robertcollins.net
Sat Dec 7 01:20:02 UTC 2013


On 7 December 2013 09:31, Liz Blanchard <lsurette at redhat.com> wrote:
> This list is great, thanks very much for taking the time to write this up! I think a big part of the User Experience design is to take a step back and understand the requirements from an end user's point of view…what would they want to accomplish by using this UI? This might influence the design in certain ways, so I've taken a cut at a set of user stories for the Icehouse timeframe based on these requirements that I hope will be useful during discussions.
>
> Based on the OpenStack Personas[1], I think that Anna would be the main consumer of the TripleO UI, but please let me know if you think otherwise.
>
> - As an infrastructure administrator, Anna needs to deploy or update a set of resources that will run OpenStack (This isn't a very specific use case, but more of the larger end goal of Anna coming into the UI.)
> - As an infrastructure administrator, Anna expects that the management node for the deployment services is already up and running and the status of this node is shown in the UI.
> - As an infrastructure administrator, Anna wants to be able to quickly see the set of unallocated nodes that she could use for her deployment of OpenStack. Ideally, she would not have to manually tell the system about these nodes. If she needs to manually register nodes for whatever reason, Anna would only want to have to define the essential data needed to register these nodes.

I want to challenge this one. There are two concerns conflated. A)
seeing available resources for scaling up her cloud. B) minimising
effort to enroll additional resources. B) is a no-brainer. For A)
though, as phrased, we're talking about seeing a set of individual
items: but actually, wouldn't aggregated capacity being more useful,
with optional drill down - '400 cores, 2TB RAM, 1PB of disk'

> - As an infrastructure administrator, Anna needs to assign a role to each of the necessary nodes in her OpenStack deployment. The nodes could be either controller, compute, networking, or storage resources depending on the needs of this deployment.

Definitely not: she needs to deliver a running cloud. Manually saying
'machine X is a compute node' is confusing an implementation with a
need. She needs to know that her cloud will have enough capacity to
meet her users needs; she needs to know that it will be resilient
against a wide set of failures (and this might be a dial with
different clouds having different uptime guarantees); she may need to
ensure that some specific hardware configuration is used for storage,
as a performance optimisation. None of those needs imply assigning
roles to machines.

> - As an infrastructure administrator, Anna wants to review the distribution of the nodes that she has assigned before kicking off the "Deploy" task.

If by distribution you mean the top level stats (15 control nodes, 200
hypervisors, etc) - then I agree. If you mean 'node X will be a
hypervisor' - I thoroughly disagree. What does that do for her?

> - As an infrastructure administrator, Anna wants to monitor the deployment process of all of the nodes that she has assigned.

I don't think she wants to do that. I think she wants to be told if
there is a problem that needs her intervention to solve - e.g. bad
IPMI details for a node, or a node not responding when asked to boot
via PXE.

> - As an infrastructure administrator, Anna needs to be able to troubleshoot any errors that may occur during the deployment of nodes process.

Definitely.

> - As an infrastructure administrator, Anna wants to monitor the availability and status of each node in her deployment.

Yes, with the caveat that I think instance is the key thing here for
now; there is a lifecycle aspect where being able to say 'machine X is
having persistent network issues' is very important, as a long term
thing we should totally aim at that.

> - As an infrastructure administrator, Anna wants to be able to unallocate a node from a deployment.

Why? Whats her motivation. One plausible one for me is 'a machine
needs to be serviced so Anna wants to remove it from the deployment to
avoid causing user visible downtime.'  So lets say that: Anna needs to
be able to take machines out of service so they can be maintained or
disposed of.

> - As an infrastructure administrator, Anna wants to be able to view the history of nodes that have been in a deployment.

Why? This is super generic and could mean anything.

> - As an infrastructure administrator, Anna needs to be notified of any important changes to nodes that are in the OpenStack deployment. She does not want to be spammed with non-important notifications.

What sort of changes do you mean here?

----

Thanks for putting this together, I love Personas as a way to make
designs concrete and connected to user needs.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list