Feedback on the Glue2 draft

Balazs Konya - NorduGrid

1) How to represent traditional batch queues? Shall queue name be present in "share"? How to handle the case where one endpoint contains multiple shares (queues)? How to request a certain share?

Sergio: as pointed out in the last telecon, a share can maps to a batch queue (see added MappingQueue attribute); multiple shares can maps to the same batch queue; it is not foreseen the opposite;

• a traditional batch queue can be represented as a share
• there are three options which requires anyway profiling current specs:
  • JSDL parameter
  • BES message parameter
  • embedding in BES URL

2) How to express inheritance/specialization in xml rendering?: service -> computingservice, endpoint -> computingendpoint, share -> computingshare, etc..

suggestion: <ComputingService type="Service">, <ComputingEndpoint type="Endpoint">

Sergio: TBD

3) Do we support services belonging to multiple admindomains?

Sergio: the only way that I foresee is indirectly via hierarchical adminDomains; the current model envisions that an AdminDomain is the solely responsible for the management of the service, but AdminDomain can have hierarchical structure

4) Shouldn't be there ID for policy entities? (policy, managementpolicy, accesspolicy,..)

Sergio: TBD

5) Endpoint: Specification, ImplementationName, SupportedProfile: confusing atributes for very similar thing

Sergio: it can be between Spec and SupportedProfile; not ImplementationName since this is the name that an implementor gives to its component (e.g., CREAM can be the ImplementationName of a BES Specification with HPC SupportedProfile); anyway TDB

6) Endpoint:Type, Service:Type. What shall go here? In general, we need to work more on the enumeration types.

Sergio: definitely, to be done

7) suggestion: change job to ComputingActivity, after all, it is a specification of Activity

Sergio: done in draft 24

8) ComputingActivity (job) should have an attribute for the job's EPR.

Sergio: TBD

9) The case of multiple policy entities associated with one endpoint: is this necessary? Shouldn't there be only one policy entity per endpoint per policy schemas?

Sergio: to be checked

10) We found that the current model carries the following assumption wrt the association of share and execution environment: an execution environment is assigned as a whole to the share. That is if an ExecutionEnvironment has 10 instances then all that 10 instances must be assigned to the related share once an association between Share and executionenvironment is made

Sergio: yes, this is what is currently modeling; consider that the share can have limitations such as MaxRunningJobs which will limit the number of instances that you can use; at the moment, we advertise what types of execution environments you can access via a share; we do not have the granularity of how many instances per type of execEnv in a given share; this might be difficult to achieve and too complex to use; anyway open to discussion

12) We propose that in the xml rendering the relations are grouped within a <Relations> element and many-to-many relations are represented as n instances of 1-to-many relations. An example:

<Relations>							   		   
    <ComputingEndpoint_ComputingShare>				   		   
        <ComputingEndpointID>urn:endpoint:1</ComputingEndpointID>  		   
        <ComputingShareID>urn:share:1</ComputingShareID>	   		   
        <ComputingShareID>urn:share:2</ComputingShareID>	   		   
    </ComputingEndpoint_ComputingShare> 			   		   
    <ComputingShare_ExecutionEnvironment>			   		   
        <ComputingShareID>urn:share:1</ComputingShareID>	   		   
        <ExecutionEnvironmentID>urn:exec:1</ExecutionEnvironmentID>		   
    </ComputingShare_ExecutionEnvironment>			   		   
    <ComputingShare_ExecutionEnvironment>			   		   
        <ComputingShareID>urn:share:2</ComputingShareID>	   		   
        <ExecutionEnvironmentID>urn:exec:1</ExecutionEnvironmentID>		   
    </ComputingShare_ExecutionEnvironment>			   		   
</Relations>							   		   

Sergio: ok, take note for next revision 13) We discovred the need to group entities of the same kind: in the xml rendering for performance reasons and for the sake of clarity we'd prefer to group entities of the same kind possibly occuring with numerous instances: These are the ComputingActivity, Service, ApplicationEnvironment entities:

<Grid>
    <AdminDomain>
        <Contact>         
        </Contact>
        <Location>          
        </Location>
        <Services>
            <SpecialService type="Service">  
	      <ID>A</ID>                
                <Type>org.nordugrid.isis</Type>
                <QualityLevel>test</QualtyLevel>
                <Complexity>endpoint=1,share=0,resource=0</Complexity>
                <Endpoint type="Endpoint">
                    <ID></ID>
                    <Downtime>                       
                    </Dowtime>
                    <Policy>
                        <ID></ID>
                        <Scheme>BASIC</Scheme>
                        <Rule>VO:A</Rule>
                        <Rule>VO:B</Rule>
                        <TrustedCA>GenivaCA (DN!)</TrustedCA>
                    </Policy>
                    <Activities>    
                        <ServiceActivity type="Activity">
                            <ID>1</ID> 
                            <Type>TypeA</Type>                           
                        </ServiceActivity>
			<ServiceActivity type="Activity">
                            <ID>2</ID> 
                            <Type>TypeA</Type>                           
                        </ServiceActivity>
                    </Activities>
                </Endpoint>	      
            </SpecialService>
	    <ComputingService type="Service">  
	      <ID>B</ID>           
            </ComputingService>
        </Services>
    </AdminDomain>
</Grid>

Sergio: ok, take note for next revision