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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
