On 09/12/13 15:20, Lars Marowsky-Bree wrote: > On 2013-09-12T16:56:35, Andrew Beekhof <and...@beekhof.net> wrote: > >>> The most directly equivalent solution would be to number the per-node >>> in-flight operations similar to what migration-threshold does. (I think >>> we can safely continue to treat all resources as equal to start with.) >> Agreed. Perhaps even repurpose/rename migration-threshold for the task? >> Or is this typically set much lower than max children? > > It's typically set lower, because migration speed degrades if the > network becomes overloaded. > > Also, it's slightly different - "migrate_to" already affects the target > node, while "migrate_from" still affects the source still. > > I think "migrate" is a valid special case, though I think probably some > code can be shared - so should the need arise to limit, say, specific > ops of specific types in the future, it can be added in easily. But I > really don't want to give them that much rope to start with ;-) > > But we could introduce a name change (while still accepting the existing > one to remain backwards-compatible) to be more consistent. > > 1. Global property: operations-limit, operations-limit-migrate (alias > for migration-threshold) How about to keep it "migration-limit", and name the new property "actions-limit" -- Other global properties use the term "action". And since "migration" is known as one type of the "actions".
> 2. Can be overriden via a per-node attribute Makes sense. > 2.a. How do to that for operations-limit-migrate? Choose the lower of > the two node's values. Matched actions can be counted against the limits respectively for every node. (-- Whether the number of migrate_to/migrate_from actions on this node is reaching the migration-limit. And whether the number of all the actions on this node is reaching the actions-limit.) We don't need to alter it internally I think. One of the limits will just be reached first. > > Name might be a bit too long. And 2.a. might be overdoing it, but while > we're at it ... ;-) > > > This gives me some pain, though, and I'd welcome advise: > >>> Though the transition from an environment variable to a CIB node >>> attribute (inherited from a cluster-property, I assume) is going to suck >>> for the upgrade path :-/ > > The DC can't read the environment variables, and it's not so easy to > feed them back to the DC. > > Auto-tuning has a similar problem. The DC just doesn't know the number > of cores (and 2 * cores is the natural default, with migration-threshold > perhaps defaulting to cores / 2). The LRM at least could get that from > the local system (either /proc or sysconfig). > > Should we default the global value to the numbers from the current DC if > unset? Probably it's the only feasible way for now. Regards, Gao,Yan -- Gao,Yan <y...@suse.com> Software Engineer China Server Team, SUSE. _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
