Re: [Xen-devel] [OSSTEST PATCH] README.planner: Document the resource planning system

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-11-20 at 18:07 +0000, Ian Jackson wrote:

> +   Automatic runs create a new ownd task for each job (in become-task

At first I thought ownd was a typo for owned, but I see that it is
called this in the source...

> +The main client in the planning process is
> +ts-hosts-allocate-Executive.  That program contains the heuristics for
> +choosing good tests hosts under various conditions.

s/tests/test/ I think, or maybe an apostrophe?

> +
> +Command-line users can use mg-allocate -U to obtain resources through
> +the planning process.  mg-allocate participates with a high queue
> +priority so that command-line allocations will take precedence over
> +automatic test runs.  (mg-allocate without -U bypasses the planner and
> +can be used to `grab' resources which happen currently to be free.)
> +
> +The distinction between `idle' and `allocatable' resources exists so
> +that newly-freed resources are properly offered first to the tasks at
> +the front of the queue.  ms-ownerdaemon sets all idle resources to
> +allocatable at the start of each planning cycle.

This paragraph makes the first reference to this idle vs. allocatable
concept, but seems to expect that these have already been discussed.

Perhaps s/The/A/ at the start would help but I think more is needed. It
is implied (I think) that the allocation strategy described in all of
the preceding paragraphs operates only on allocatable resources and not
idle ones, or maybe vice versa? Or maybe one or the other is only
available to tasks at the front of the queue? Anyway, can this be made
explicit please.

Having read further I now see this is describe somewhat in the 'types of
task' section. So perhaps all which is needed is a forward reference, or
some rejigging of the ordering of the doc.

> +If the ms-ownerdaemon fails and is restarted, the tasks which were
> +clients of the previous ms-owerdaemon cannot be automatically cleaned
> +up.  The new ms-ownerdaemon will annotate them with `previous'.  The
> +administrator can then clean them up manually, if she knows that all
> +the corresponding actual processes are no longer running.

Perhaps the recipe for this cleanup could be added to README.dev?

> +
> +
> +Types of task
> +-------------
> +
> + * static tasks.  Usual for command-line use.  They are manually
> +   created (with ./mg-hosts manual-task-create) and not normally ever
> +   destroyed.

FWIW there is an explicit example of this in README.dev.

> +     magic/idle
> +
> +        The resource is free but has perhaps only recently become so.
> +        It can be allocated outside the planning process, but proceses

"processes".

> +        participating in planning should regard the resource as
> +        unavailable.
> +
> +     magic/shared
> +
> +        The resource has been divided into shares.  It is unavailable
> +        in its own right without being unshared first.  The individual
> +        shares have their own owners.

"See below for more information on sharing".

(I was just about to ask something which is answered down there...)

> +
> +Sharing
> +-------
> +Likewise a process which finds a shared resource completely idle can
> +unshare it.  That is:
> +    * Check that all the shares are allocatable
> +    * Delete all the rows representing the shares

Is there a race here? Or does the check actually imply allocates each of
them to itself?
 
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel