Bah, sorry that I'm late on this. To Michael's question, I think the intent of "Any" was "I don't care, move them from their nodes and put them wherever", which may be an important thing, or not, to have.
Anyway, the suggested behavior for "Any" (always try current group first, even if it's last_resort) sounds appropriate to me. As for the last point, what about: the instances will be moved away from their current group, to any of the groups in this list + (which may not include any of the origin group where the instances + currently live) ? Cheers, On Mon, May 30, 2011 at 14:12, Iustin Pop <[email protected]> wrote: > Hi all, > > While working on implementing this new call in htools I met some rough > edges of the new spec :) > > The biggest issue is that we don't currently have a way to score > multi-group clusters. We can score single-group clusters rather well, > but scoring correctly a multi-group cluster is not yet solved. > Allocation on multi-group clusters does an ugly hack where we compute > the score across the entire cluster as a single group, which is clearly > inappropriate. > > Next, the 'any_group' mode. I know we had some reasons to introduce > this, however I can't how this an IAllocator is supposed to make its > decision correctly. The issue is that we don't know if inter-group moves > are costly, and we can't thus decide whether to keep in-group for a > decrease in current group score of 0.2, or to move to another group for > an increase of 0.1 only (for that target group). The only sane choice I > see is that we always try the current group and only if that fails, we > will relocate to another group. In effect this is not 'any_group', but > 'change_if_needed'. > > The design also says: “In all modes, the groups’ alloc_policy attribute > will be honored”. However, it is not clear to me how this should work in > any_group mode when the current group is 'last_resort'. Should it just > skip the current group, before any score computations? Note that the > instance is already in this group, so it's not a new allocation. > > Evacuating from multiple groups: the current design allows specification > of instances which live on different groups. While this might make sense > in keep_group and change_group mode with target_groups not the groups > from which we evacuate the instances, when we go change_groups with > target_groups one that are being touched or in any_group mode, there > isn't a clear meaning for what the operation should do. So I think we > should disallow this in the design (I won't implement it anyway in > htools). > > And that's about it for now, but I'm sure more problems will crop up :) > > iustin > -- Adeodato Simo | [email protected] Corp Computing Services SRE (Dublin)
