On Fri, Mar 25, 2011 at 09:07:23PM +0000, Adeodato Simo wrote: > > Signed-off-by: Adeodato Simo <[email protected]> > --- > > Hi, > > this is a cleaned-up version of the discussion we had on inter-group > instance moves. > > The design for shared storage went in shortly after our discussion; I've > read that design document now, to see if it altered our proposal at all. > I could only see that the IAllocator will have to consider mobility > domains, so I've added a couple mentions to that. > > While writing this document, for a moment I *thought* that the "mode of > operation" attribute of the IAllocator call was redundant: by just > accepting a list of node groups, it seemed "Any" could be expressed by > listing all groups, "Stay in group" by listing only the current group, > and "Change group" by listing the desired target groups (e.g. X and Y, > or all but the current group). > > Later I realized, the listed instances need not belong all to the same > group, so the design below is richer than a pure list of node groups. > > If you think this needs explicit mentioning in the document, please let > me know.
I haven't read the patch yet, but I wanted to comment on your thought. I have already considered and discarded that option during our (offline) discussion, but I wasn't explicit about it. I believe that _implying_ staying in the current node group via specifying the same group name is a slightly worse design, as it's just an implication. "Stay in group" is explicit about the intention, instead of suggesting it. Similarly, "Change group" is explicit, whereas passing in a list of all the other node groups is not. While this won't matter directly to the tools themselves, debugging (by people) will be much helped via this explicit signalling versus the implied one, where you have to scan the message, parse where the instance(s) are, and re-compute what the meaning behind the request was. Hence my not even mentioning this possibility- sorry for not being explicit! The point about evacuation from multiple groups is a good one. thanks, iustin
