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

Jaromir Coufal jcoufal at redhat.com
Mon Dec 9 09:57:52 UTC 2013

On 2013/07/12 02:20, Robert Collins wrote:
>> - 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.
Yes, in ideal world and large deployments. But there might be cases when 
Anna will need to say - deploy storage to this specific node. Not 
arguing that we want to have policy based approach, but we need to cover 
also manual control (forcing node to take some role).

>> - 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.
I think by this user story Liz wanted to capture that Anna wants to see 
if the deployment process is still being in progress or if it has 
finished/failed, etc. Which I agree with. I don't think that she will 
sit and watch what is happening.

> - 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.
Node being serviced is a different user story for me.

I believe we are still 'fighting' here with two approaches and I believe 
we need both. We can't only provide a way 'give us resources we will do 
a magic'. Yes this is preferred way - especially for large deployments, 
but we also need a fallback so that user can say - no, this node doesn't 
belong to the class, I don't want it there - unassign. Or I need to have 
this node there - assign.

>> - 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.
I believe this has something to do with 'archived nodes'. But correct me 
if I am wrong.

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

More information about the OpenStack-dev mailing list