Who publishes UserDomains?
Hi all, Here's a potentially tricky question: who publishes the UserDomain objects? Consider an SE agent wishes to publish the "ownership" of the StorageShare objects. To do this it should publish MappingPolicy objects, each of which will need to know (MappingPolicy: UserDomain.ID link-end 1..*). To get these UserDomain.IDs the agent has two possibilities. Either: 1. The SE publishing agent creates its own set of UserDomain objects; given this, it knows the UserDomain.ID 2. The SE queries for existing UserDomain objects for ones matching its requirements, so discovering the appropriate ID Problems with solution 1. --- Some client queries become (unnecessarily?) complex unless some form of merging takes place. How does a client know which set of UserDomain objects is really the VO "ATLAS"? One possible approach would be to merge the UserDomain objects that represent the same end-user-group (e.g., the same VO). Unfortunately, this would likely be a fragile and incomplete process with the current set of attributes. Clients that want to query against resources for some VO (e.g., ATLAS) would have to support querying against multiple UserDomain objects. Problems with solution 2. --- How should an agent discover which UserDomain object to use? There's no attribute(s) useful for identifying a VO (or group within that VO) from characteristics; for example, publishing a VOMS prefix. What should the publisher do for end-user groups that don't currently exists? If it publishes a (minimal) UserDomain object itself, then there's a potential race-conditions with multiple UserDomain objects being published. Requiring some information to exist before publishing primary data will make the publishing process fragile. For example: Temporary outages will have a knock-on effect: the info-service would be as reliable as each of the UserDomain publishing agents and the network links from these to all other grid components. If data is cached (local to the agent) is used to improve reliability, it's possible for publishers to use outdated information, so providing useless information, potentially affecting that VO's usage of the resource. Which agents are responsible for publishing VO UserDomain information? Would this be another centralised component and another barrier to forming a new VO? What do others think? Cheers, Paul.
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: Here's a potentially tricky question: who publishes the UserDomain objects?
At the schema level we don't define anything about how things are published. Even at the level of the concrete representation it isn't necessarily defined, for example the current LDAP DIT reflects the "site bdii" structure in which things are published but it wouldn't necessarily have to be like that. If the UDs are published at all I would guess that they would be most naturally published with the VOMS servers, either directly with the service or in some other way by the hosting site. However, there are other possibilities, e.g. centrally (all EGEE VOs from CERN?) or ad hoc (someone in each VO makes arrangements at a local site somewhere).
1. The SE publishing agent creates its own set of UserDomain objects; given this, it knows the UserDomain.ID
No, it can't do that!
2. The SE queries for existing UserDomain objects for ones matching its requirements, so discovering the appropriate ID
I think you would configure it statically, not try to get it dynamically. However, I suggest you don't worry about it at this stage; I'm skeptical that UDs will be published at all, and even if they are I'm not sure if you would actually bother to fill in all the Policy-UD references as there might well be no use cases that would need to navigate them. Anyway this isn't conceptually different from other potentially cross-site relations, like CE -> SE.
How does a client know which set of UserDomain objects is really the VO "ATLAS"?
It (probably) doesn't care, it just knows that rules in a particular schema have forms like "VO: atlas" or "VOMS: /atlas/*". Stephen -- Scanned by iCritical.
Hi Paul, all,
Consider an SE agent wishes to publish the "ownership" of the StorageShare objects. To do this it should publish MappingPolicy objects, each of which will need to know (MappingPolicy: UserDomain.ID link-end 1..*). [...]
That should be 0..* for reasons deliberated by Stephen: we must not force UserDomain objects to be published. This needs fixing in the document.
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Maarten.Litmaath@cern.ch said: That should be 0..* for reasons deliberated by Stephen: we must not force UserDomain objects to be published. This needs fixing in the document.
I'm not entirely sure what multiplicity 1 means for relations - I don't think it requires the object to be published, just that if it is published there should be at least one of it. Conceptually it probably is true that a MappingPolicy is always associated with at least one UserDomain, even if it only consists of a single user! (Although in some cases the "user" could be a robot rather than a person ...) However, there is then a separate question: even if the related object does exist is it necessary to publish the relation attribute, even if there is no use case which would ever need to navigate it? I don't think we've considered that question ... Stephen -- Scanned by iCritical.
participants (3)
-
Burke, S (Stephen) -
Maarten.Litmaath＠cern.ch -
Paul Millar