Etienne Urbah on 2010-03-26

• Propose requirement with title  'For requests querying Activity Status, the Information Service MUST accept, as input parameter, complex queries on Activities expressed according to the GLUE2 model without explicit specification of the Activity IDs.  The Information functionality MAY support multiple query languages in addition to the mandatory one.'

Etienne Urbah's position on 2010-04-14

• There is an absolute need to be able to query NOT yet finished Activities by :
• The grid identity of the Activity submitter, in particular :
  - For all grid users :    What is the Status of all my currently NOT yet finished Activities ?
  - For a VO manager :  Which grid resources are currently used by Activities submitted by one precise member of my VO ?
• The activity Status, in particular :
  - For all grid users :    Which Applications, Storage Resources, ... are referenced by Activities submitted by me but NOT yet running on a Computing Resource ?
  - For a VO manager :  What are the top Applications, Storage resources, ... referenced by Activities submitted by my VO but NOT yet running on a Computing Resource ?
• The Information Service SHOULD NOT provide the above queries as a special case for Activities, but SHOULD provide generic complex queries for all grid entities, so that the above queries are simply a particular case of generic complex queries
• This introduces complexity inside the grid component(s) implementing the Information Service, so that this requirement is NOT likely to be achievable by a grid service having already performance requirements
• This requirement is within scope for the Information Service, and should be out of scope for the Execution Service
• Anyway, it is better to keep that clearly written down, so I vote FOR this requirement

Morris, Balazs and Etienne on 2010-04-21

• Dropped (rejected), because of information service unclarity

Etienne Urbah's addition on 2010-04-21

• Replacing 'Information Service' by 'Information functionality' inside the title would permit to re-propose this requirement
• But the details about the input parameter would probably be rejected anyway with status 'Premature (Detailed specification)' like requirement LB6
• So, let this requirement in the 'Rejected' status for the moment

Etienne Urbah's retry on 2010-05-05

• This requirement can be compared to requirement JM6.15, which has been accepted for discussion
• Therefore, re-propose this requirement
• Change the requirement status from 'Rejected (Bad prerequisite on Information Service)' to 'Re-proposed'