Reference Model and GLUE integration

• Reference Model
  • (UML) Grid Component Hierarchy
  • (UML) Grid Component Relationships

• GLUE
  • (UML) Main Entities
  • (UML) Computing Entities
  • (UML) Sequence Diagram of a job submission
  • GLUE Spec, latest draft

• GLUE and Reference Model
  • (UML) Deriving GLUE entities from the Reference Model

Open Questions

(1) AdminDomain and physical locations

Paul stated that an AdminDomain can span different physical locations; what about the resources being managed? Should they be related to their physical location?

From the GLUE viewpoint , so far we needed only one "main" physical location for an adminDomain; we did not need to represent different physical locations for the single resources part of the same adminDomain, nor this is a valuable information for resource selection;

since we want to keep glue enough simple to be usable, should be stick to this view? what is the advantage of representing many physical locations for a single admin domain (in terms of use cases to be satisfied)?

from Paul - Different locations only matter if their resources and services are managed separately at each location for some reason, for example if two locations are a long distance apart and data is only at one location and latency is too high or bandwidth constrained, then you may care a lot abour co-locating at a single physical location and having a single meta-scheduler instance at each location or ensuring that your meta-schedular understands location. This matters a lot at eBay, but you may not care for your workload. If you think you may care in the future, then it may be worth capturing this.

from Sergio -

• discovering co-location of computing and storage or computing and data is also an issue for our use cases; the co-location of computing and storage is an issue for GLUE; the co-location of computing and data is typically handled indirectly by deriving the storage where the data of interest is placed (this is resolved by catalogue services)
  
• we are interested in capturing the co-location of computing and storage, nevertheless, the physical location solves the problem only if you can assume that all the resources present at the same location share the same network connectivity; this is not always the case

(2) adminDomain hierarchy

do we want to model hiearchies of adminDomain? The current EGEE infrastructure already follows a hierarchical pattern, nevertheless this is not yet captured by GLUE

(3) how to split the computing share

during last RM call, it was identified that the share contains two main categories of attributes that fall into two different management aspects:

• policy: e.g. on resources (which exec environment are considered), on jobs (MaxWallTime), users (who can access the share)
• status: e.g., RunJobs, Estimated Response Time

my proposal is to split the share into two parts:

Computing Share as composed of Computing Share Policy and Computing Share State

from Paul - I think that Share is two parts, policy and status, associated with a new abstraction, that is the set of services exposed to a given consuming organization, i.e. the organization that has negotiated the share with the admin domain that manages the resources and services. I called this another container, but I am not wed to any name. I do however think it important to identify this new managed grid component, which only exists in the abstract, and with which all jobs done by users within the consuming organization are associated. The SLO policy is applied to this managed component. In reality there is only really a managing component that ensures that all of the Elements (as described by the GLUE group) get an appropriate service level and which aggregates accounting information and usage so that it applies to the set of users/jobs, not just to an individual user/job.

from Sergio

• as regards the computing share, we have to consider that this is typically implemented by configuring different services. For instance:
  • (1) the identity mapping service which maps Grid credentials to local credentials;
  • (2) the local batch system to be configured to serve jobs submitted using some local credential in a way consistent with the service that should be provided to the related Grid-level credential

(4) Element or not Element

The Element at the moment is used as an aggregation pattern of concepts that are needed to define a Grid functionality; An example is the Computing Element; an instance of computing element aggregates all the instances of the concepts needed to provide a computing functionality in a Grid sytem. Currently, the only envisioned attribute is a persistent name and a relationship with the AdminDomain; more attributes can be later needed;

Example of elements are: service element (element made only of a service, the simplest), computing element, storage element

Not everybody agree on the idea of adding the Element as a concept; the other position is to remove the element and relate the services/resources directly to the admin domain

Pro/con?

from Paul - The notion of element or container, as I put it, is important if you want to manage multiple components (services, resources, execution environment etc.) related to one thing, i.e. a job. I think it makes sense to have the notion of a container of some sort (whatever your choose to call it) that is created by the management software, for the job to run "in".

from Sergio - I do agree for the need of this concept; not sure about the proper name to be given; element, container, system ??

(5) check that all glue entities derive from RM entities

• element is a RM::pattern?

from Paul - One could consider an Admin Domain to be a managing grid component, specifically the common ancestor of all managing grid components that manage the life cycle of resources and services within that admin domain.

from Sergio

• ok, added adminDomain as specialization of RM::managerComponent
• about Share, in the current proposal this is modeleded as composed of Share Policy and Share Status; is this a good approach? how would you place Share and Share State in the specialization from RM model?
• in GLUE we are evaluating the addition of Organization entity; we haved
  • RealOrganization (RO, for administrative institutes like INFN, eBay, etc) managing resources and offering them to a Grid infrastructure
  • VirtualOrganization (VO) considering the users requiring access to Grid resources; they are typically into groups; groups and users can have roles; authorization policies to shares can be either VO-wide or per-group or per group/role; you may have authorization like "the all VO but not a certain VO group" (e.g., because that VO group is authorized to a dedicated share)
  • the members of a VO (users) consume the services (possibly constrained by shares for which they have authorization)
  • the members of a RO manage resources/services but do not use the resources;