[glue-wg] Model Questions

[Sergio Andreozzi]

Hi Donal,

Donal K. Fellows ha scritto:
> Hi everyone
>
> I've been looking through the current draft and I've got a few
> questions... :-)
>
> 1) Should the Policy class have Scheme and Rule attributes? They seem to
> be common across a number of subclasses.
>   

Policy is the last area of the main entities to be reviewed; this is 
going to be a tough discussion because I spoke to a number of people 
related to security and they are against the modeling of this concept in 
GLUE. This because the main customer of GLUE will be the information 
service. If you put policy in there, people will use the information 
service as a policy decision point, but the info service does not fit 
the requirements of an authorization system...

we'll talk probably next week about this.
> 2) What's the relationship between Mapping Policy and Share Policy?
>   
it's a policy that states if your request can be mapped into a certain 
share.
> 3) Should the Downtime class relate to a Service instead of an Endpoint?
>   
given our discussions it seems more appropriate for endpoint since you 
can schedule for maintenance just an endpoint
> 4) Are Shares inherent features of all Services in the GLUE model, or
> can a particular subclass of Service not use them? (Might they only be
> features of Computing Services? Might they only be features of
> particular important subclasses of Computing Services, i.e. those with
> queues?)
>   
at the main entities level, they are optional and abstract; we have not 
found any use case so far for instantiating them at this level; they are 
important anyway as a pattern for subclassing services (e.g. see 
Computing Service)
> 5) Why is Share State separate from Share? Does it relate to Service state?
>   
no, it doesn't. From the reference model WG, it was recommended to split 
policy and state. Actually state properties could be part of the Share class
> 6) In the Information Model level, I'd be strongly tempted to just say
> that integers are integers and not give the width of the integers.
> (That's more appropriate for the data model.)
>   
the problem is that we have to map into different data models, therefore 
we should be clear at the conceptual model level what is the range of 
values otherwise transformation from data model to data model may fail; 
the CIM conceptual model follows the same approach
> 7) There are unit mistakes in Computing Share Policy. (I also strongly
> recommend only using SI base units (plus bytes) for units.)
>   
this is yet a draft to be reviewed
> 8) What is the relationship of the Execution and Application Environment
> classes to the core GLUE model?
>   
no relationships; they are new classes added for Computing Service; they 
inherit from the reference model (see section 7)
> 9) I've had systems in the past where the job acquired a Usage Record as
> a property when it completed. That worked quite well.
>   
are you suggesting to add an attribute to the hob entity which is 
UsageRecord?
> 10) You probably should talk to the OGSA-DMI-WG folks about the Storage
> Endpoint class's attributes.
>   
we are a bit far from this discussion yet
> 11) There needs to be a relationship between Compute and Storage sides
> (essential questions are probably "where can I get the output of the Job
> from?" "where do I ship my input data to in order to run on that
> system?" and "where can I run my job so that I don't need to ship the
> data about unnecessarily?"). That's a very important relationship! :-)
>   
yes, I know very weel this issue; consider that we are finalizing the 
revision of main entites and yet to move to computing
> 12) Do you plan to construct a dictionary of Application names? If not,
> it's going to make finding Application Environment instances tricky in
> practice. This will also need to tie in with JSDL, HPC Profile and ACS
> groups. Maybe also OGSA Naming, though I believe they name something
> else. If you do, it probably should be in a separate document. (I'd
> suggest some sort of structured name so that you don't need to name
> everything!) It's also a shame that CIM hasn't done anything in this
> area that I can see...
>   
probably not; we may go for open enumeration but no discussion yet. 
Maintaining a dictionary of application names could be difficult to 
achieve and probably not worth the game.

Cheers, Sergio


-- 
Sergio Andreozzi
INFN-CNAF,                    Tel: +39 051 609 2860
Viale Berti Pichat, 6/2       Fax: +39 051 609 2746
40126 Bologna (Italy)         Web: http://www.cnaf.infn.it/~andreozzi