[RUS-WG] Minutes from the OGF20 sessions

[Rosario Michael Piro]

Hi Gilbert, hi everybody!

Gilbert Netzer wrote:
> Hi everybody,
> 
> the minutes (as well as the slides) from the RUS and RUS+UR session at the 
> OGF20 in Manchester are now available on the GridForge in the following folder:
> 
> http://forge.gridforum.org/sf/go/projects.rus-wg/docman.root.meeting_materials_and_minutes.ogf20_manchester
> 
> Please have a look an tell me if something is wrong/missing/too much!

Very good minutes, very detailed, I can't imagine that something is 
missing :o)

Many of us have been present at the sessions I think we should give 
those who haven't the possibility to express their opinions such that we 
can then take final decisions (although most are already now quite 
clear, but having other point of views can be interesting, so please 
read the minutes if you couldn't attend the sessions at OGF20!)

I've already a few considerations to some of the things we said at the 
sessions, maybe they can serve as a starting point for a discussion.

1) Comments to the minutes of the joint UR/RUS session:

Aggregation of usage:
- Most of us think that a separate AUR specification would be most 
appropriate and allow to contemporarily work on both aggregation and the 
extension of the UR to resource consumers other than jobs (e.g. for 
storage accounting, etc). Also, a preliminary proposal has been made 
that we can start working on (and I'm sure Xiaoyu would take the lead on 
that as principal editor of the document)
- Xiouyu, the version of the proposed AUR spec currently available at 
http://forge.ogf.org/sf/go/doc13708?nav=1 is quite old (before we 
modified it to have it more flexible for more use cases), can you 
provide the UR-WG (and RUS-WG) mailing list with the latest version, so 
that interested people can have a look at it and start a serious 
discussion on the topic?
- About the name: currently Aggregate Usage Record (AUR), or would the 
name Summary Usage Record/SUR be more appropriate, since aggregation can 
also mean just a set of single URs without summing the usage values up?

Proposed new properites of UR:
- UserFQAN: The FQAN is indeed very well structured (as is the User DN), 
it is basically a string that indicates the VO and particular VO group a 
user belongs and has additional fields for the user's role/capabilities 
within that VO, something like: 
"/VO[/group][/Role=...[/Capability=...]]", for example: 
"/atlas/production/Role=admin". For a brief description see Section 2 of
http://grid-auth.infn.it/docs/AC-RFC.pdf
Note that a VOMS certificate may have multiple FQANs, such that the 
property should have an unbounded occurence.
Since VOMS is widely used (and for example charging might depend on a 
user's role in a VO) the notion of a user's role should be supported 
although that need not necessarily be restricted to the VOMS FQAN. Maybe 
something more flexible like urf:UserRole might be ok (those who don't 
use VOMS might still be interested in distinguishing between "admins" 
and "mortal users", UserRole might simply be defined as a string and the 
exact form of it should then depend on the environment/use case. But 
that's just an idea.

2) Comments to the minutes of the joint UR/RUS session:
[I keep the UR-WG in CC for this, some of you might be interested in 
what is going on eith RUS; if not, just ignore what is following ;o) ]

Full XPath support vs. XPath limitations:
- I wouldn't say that XPath queries destroy the performance, although 
they of course can slow it down, that depends on the complexity and also 
on the underlying database. Even with a relational DB schema the 
execution of a query can be awfully slow if an XPath has to be 
translated into an SQL statement that will cause many tables to be 
joint. Also, I think the most problematic part of the query is the 
selection of the requested records within the maybe millions of records 
in the database (being it relational or XML) and less the question 
whether, after these records have been found, they should be returned 
completely or just pieces of them (maybe returning complete records is 
even worse for the performance, for example if a relational DB is used 
which means the server will needs to reassemble the complete UR 
documents before returning them ...?). But I think although we should 
keep performance issues in mind (nonetheless we can't forsee many 
problems without having experienced a lot with this), we should not 
focus too much on that. The question is more whether we want the RUS 
interface to be completely XPath-compliant or leave the restrictions 
that are currently in place. I think full compliance is the better 
choice, above all since we're talking about standards :o)
- If XPath will allow to retrieve only pieces/parts of URs: Why should a 
client need to validate what it got back against the UR spec. If I'm 
interested only in a list of job IDs than I will check only whether what 
  I got back is a list of job IDs, not wether that list can be validated 
against the UR. And if I want to do that validation, this is perfectly 
fine, since I can always ask for entire records that I can then validate 
against the spec. It is up to the client to check what it gets back 
(knowing exactly what it wanted back; entire URs for validation, just a 
list of job IDs, or whatever ...)
- I would oppose the idea to define a minimum set of XPath queries that 
have to be supported by a RUS server, since this interferes with 
implementation issues. If a RUS server, for example, doesn't want 
records to be found by UserIdentity than it always should be allowed to 
refuse the execution (maybe by returning a UserNotAuthorizedFault). If 
defining such a query in a mimimun set of queries that have to be 
support, the developer would loose that option. Generally all possible 
XPath queries should _theoretically_  be support but we need to give the 
developer the means to refuse their execution for some reasons 
(UserNotAuthorizedFault, QueryTooComplexFault, InternalServerFault, ...).
- Also I think letting the RUS server inform the client about what 
queries it is willing to execute would be unfeasible since XPath is 
extremely flexible and listing all possible queries should be quite 
impossible (immagine all the possible combinations ...).
- The idea of using XPath expressions for defining the mandatroy 
elements that have to be present for a UR to be accepted upon insertion 
is good since it is the most flexible one, also: if the client queries 
the RUS server for the mandatory elements it should be straightfoward 
for the client to test its UR documents against the servers requirements 
before trying to insert them into the RUS.

Those are just a few ideas for starting a discussion.

Cheers,

Rosario.

> 
> Best Regards
> Gilbert Netzer
> --
>   rus-wg mailing list
>   rus-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/rus-wg