Physical Reresentational relationship?
Dear all, Over and over again, I keep asking myself why a physical instance of a service is 1:1 mapped with a representation of it. For VO service discovery this is odd to my mind, especially for service discovery (Even with monitoring in the use cases this seems strange as most things are partitioned at the VO level, eg storage and computing) 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? Maybe such a change is too radical? Maybe it eliminates some benefits we currently have with our "rich" VO relationships in parts of the schema? This basic unit may reduce the entities within the schema in the style of database third normal form. This question is from me, and should not be misconstrued as representing anything other than a question, as at this stage of discussion it would appear to late to reorganise the entities into third normal form. I present it for maybe Glue 3. Regards Owen Synge Disclaimer ~~~~~~~~~~ This question is from Owen Synge and not questions from DESY or the dcache team.
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, 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. 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. On a more abstract level you could say that the publishing should be aligned with who "owns" the information. Services are run by sites, not VOs, so it makes sense for a site to publish information about all the services it runs, including who is authorised to use them (which may change from time to time). Stephen
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
participants (2)
-
Burke, S (Stephen) -
owen.synge＠desy.de