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