On Wed, 9 Apr 2008 12:26:11 +0100 "Burke, S (Stephen)" <S.Burke@rl.ac.uk> wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of owen.synge@desy.de said: In other words why does the Glue schema have a service entity which is mapped 1:1 with physical instance and not an VO-service entity?
As a minimum it saves publishing the same information many times over. Also some services are not VO-specific (e.g. BDII). Services do have the information on who is authorised to use them via the AccessPolicy, so there's nothing stopping you publishing separate services per VO,
I fear you misunderstand. Nothing stopping you publishing separate VO's, is an invalid argument when it comes to normalisation, which is the Glue WG's task as I thought it, since Glue is developing a relational schema. VO as an attribute seems to spread across many entities, most services have an access control based by VO, some services have VO as an attribute in other entities bound to services providing other functions than access control.
and indeed for most sites that's exactly what happens with the CE, i.e. there is one CE (queue) per VO - but it isn't very satisfactory because you end up with a huge number of queues.
Since with this change should eliminate all the other VO based attributes, I see this as reducing the data required, not in instance of services but in the entities and attributes associated with them, by removing duplication of VO related entities and attributes.
On a more abstract level you could say that the publishing should be aligned with who "owns" the information.
Ownership is not clearly defined in my mind, is a service for a VO or provided by a site? Ownership could be either. Personally I think the VO is a entity unfortunately cross site relations are difficult to deploy and so we need to be pragmatic (hence my suggestion of binding it to service), as it seems to be an attribute currently distributed in many objects particularly in relation to services I think adding it to Service makes some sense as then we may have less in the way of entities/attribute. to quote one point you made "Also intrinsically a VO is just
one level in a UserDomain hierarchy, you can have groupings of VOs (all WLCG VOs, all GridPP VOs) and subgroups within VOs."
Can you please explain what you mean here, Im still unsure its not again a case of misunderstanding or me being silly and missing some thing basic in your world view, a VO is a collection of users and so for the purposes of this discussion and in the context of "3rd normal form" hierarchies of user groupings are all the same thing, as they resolve to a single entity which is by definition 1 or more users. Am I wrong in believing Glue is a relational schema with the intention of 3rd normal form, which will then be mapped to a LDAP XML and RDBMS schema where performance optimisations will be added? Regards Owen