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_materia...
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@ogf.org http://www.ogf.org/mailman/listinfo/rus-wg