On Dec 9, 2013, at 4:57 AM, Jaromir Coufal <jcou...@redhat.com> wrote:
> > 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). Perhaps the use case is that Anna would want to define the different capacities that her cloud deployment will need? You both a right though, we don't want to force the user to manually select which nodes will run which services, but we should allow it for cases in which it's needed. I've updated the use case as an attempt to clear this up. [1] > >>> - 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. Yes, definitely. I've updated this use case to reflect reality in that Anna would not sit there and actively monitor, but rather she would want to ultimately make sure that there weren't any errors during the deployment process. [1] > >> - 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. This is a great question, Robert. I think the reason you bring up for Anna wanting to remove a node is actually more of a "Disable node" action. This way she could potentially bring it back up after the maintenance is done. I will add some more details to this use case to try to clarify. [1] > >>> - 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. I was assuming it would be incase the user wants to go back to view the history of a certain node. Potentially the user could bring an archived node back online? Although maybe at this point it would just be rediscovered? Thanks, Liz [1] https://wiki.openstack.org/wiki/TripleO/Tuskar/IcehouseUserStories > > -- Jarda > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
