[UR-WG] Survey Design

[piro at to.infn.it]

Hi Donal!

I think it's a good idea to start from a survey. I've added a few ideas
and comments inline.

> Hi everyone
>
> First let me apologize for letting things slide for a while; I've been
> up to my ears in the project I work on.
>
> We need to start work on designing the survey to gather experiences with
> the UR 1.0 format. I'm not quite sure how to go about this, but I
> suppose a good way to start would be to provide some kind of template
> for people to fill in. So I'm going to write some random ideas I have
> for what we should be asking; chime in if you think I'm right or wrong.
>
>    Name & Contact Email
>    Project/Product
>    Prose Description of Use
>
>    Structured Use Characterization:
>       Which UR1.0 Elements do you support? (Table, one row per spec
>       element)
>
>         Element Name | Generate | Parse
>         -------------+----------+-------
>          UsageRecord |    yes   |  yes
>          ....
>
>       What extensions do you put in a Usage Record?
>
>         e.g. executable name, working directory, arguments

This is important, I guess, for knowing what properties might be added to
those explicitly defined (if everybody is ussing it, why not add it as
regular property ...). For that purpose I suggest to ask also _how_
important are those extensions for the correct functioning of the
project/product. For example: if an accounting system can only
accept/process records containing a non-standard property (i.e. extension)
the impact on interoperability is different from cases in which an
extension is allowed but not required. A practical example: DGAS requires
the unique global resource ID (Computing Element ID) to be present in a
record (because it associates these records to pre-registered CE
accounts). This might be either put into the MachineName (that however can
also be the site name, etc.) or in an extenstion. In both cases there is a
risk of incompatibility of otherwise perfectly valid usage records (if the
MachineName contains something else or the extension is not defined). But
this is just an example, there will be other projects/products that
require specific non-standard properties (VOName, for example, is
important for nearly all large-scale Grid environments), but that is of
course something that the survey has to show. Just keep in mind that some
extensions might be more essential than others.

>
>       When do you generate usage records?
>
>         At job start.
>         At job end.
>         At points during the job.
>             What triggers the generation?
>         After the job has run from other captured data.
>             Corresponding to whole job?
>             Corresponding to events within job?

Good point, we usually talk about "periodic" accounting (after the facts;
e.g. once a day), "immeditate" accounting (right after job completion) and
"real-time" accounting (incrementally while a service is being furnished)

I'd clarify by using the expressions "at job end (upon job completion)"
and "after job ends (periodically)".

>       What do you do with Usage Records after generating them?
>
> Is there anything else that we ought to ask about?

I'd also ask how important an aggregate/summary usage record (for usage
statistics) would be, making however clear that that would be a distinct
specification (such as the one proposed by Xiaoyu). Just to have an idea
on how much effort should be put into this (as a co-chair of the RUS-WG I
say a lot ;oP , but of course it's the community that should decide).

>
> I should note here that the OGSA HPC Profile WG is looking into the
> collection of usage data from simple jobs, and that they are minded to
> use UR1.0 as the basis for this.

Can you point me to some documentation about this, reading their charter
they seem to focus on job scheduling, not building usage statistics.

Cheers,

Rosario.

>
> Donal.
> --
>   ur-wg mailing list
>   ur-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ur-wg
>