- glue-wg - lists.ogf.org

next GLUE call - Wed 21 Jan - 4 PM CET
by Sergio Andreozzi 16 Jan '09

16 Jan '09

Dear all, the next GLUE call is scheduled for Wednesday, 21 Jan, 4 PM CET: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… in this call, we will discuss the last open issues related to the Policy class. For Balazs, please confirm that you can attend it. For Flavia, there are no more storage issues, therefore there is no need for you to connect. Wish you a good weekend, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40127 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

next GLUE call - tomorrow Fri 16 Jan - 4 PM CET
by Sergio Andreozzi 15 Jan '09

15 Jan '09

Dear all, I confirm that the next GLUE call is scheduled for tomorrow, 4 PM CET: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… this will be focused on storage related open issues. Today we have no call. Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40127 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

today telecon - 4 PM CET
by Sergio Andreozzi 08 Jan '09

08 Jan '09

Dear all, this is to remind about our first GLUE telecon for 2009: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… Looking to talk to you, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40127 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

GLUE calls - schedule for Jan09
by Sergio Andreozzi 06 Jan '09

06 Jan '09

Dear all, at the following page, I've proposed the GLUE call schedule for January 2009: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeetings Due to a new job that I will start at the University of Bologna, I need to change the current slots as follows: * postpone the start of the call to 4 PM * move the Thursday call slot to Wednesday Please, let me know if you have problems with this. This set of call should be enough to finish the discussion of the pending issues for the two GLUE documents and send them to the OGF editor for being promoted to Proposed Recommendation. Best regards, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40127 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

3 3

Re: [glue-wg] [Bes-jsdl-glue] PGI kick-off teleconference details
by Laurence Field 06 Jan '09

06 Jan '09

This clashes with the Glue Schema phone conference. Laurence Moreno Marzolla wrote: > Dear all, > > To join the PGI kick-off teleconference > (http://forge.ogf.org/sf/projects/pgi-wg) on Wednesday, 2009-01-07 at 4 > p.m. CET (UTC+1), please use this calling information: > > via Skype call +9900827049931906 (free of charge) > ordinary phone numbers (local rates) with the 9931906 conference number: > > Austria 0820 401 15470 > Belgium 0703 57 134 > France 0826 109 071 > Germany +49 (0) 180 500 9527 > Switzerland 0848 560 397 > > Should we encounter technical problems with the above, we will circulate > backup instructions to use another teleconferencing system. > > Regards, > > Moreno. > >

1 0

Who publishes UserDomains?
by Paul Millar 24 Dec '08

24 Dec '08

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.

3 3

Thoughts on WLCG storage accounting use-cases
by Paul Millar 19 Dec '08

19 Dec '08

Hi all, So, I've been thinking about publishing storage related objects, particularly with the WLCG accounting use-cases. One of the use-cases calls for associating each portion of a storage element to one or more VOs so that these can be used for per-VO accounting. In Glue 2.0, this association most naturally follows from instantiating MappingPolicy objects that act as links between StorageShare objects and UserDomain objects. An interesting issue is how to represent a single shared (i.e., multiple VOs may use) StorageShare. This can be represented (equivalently) as either: a single MappingPolicy object pointing to multiple UserDomain policies or multiple MappingPolicy objects, each pointing to the same StorageShare object. Each MappingPolicy object points to a single UserDomain object, but each of these UserDomain objects is different. (In fact, these two options are two extremes: one could publish a mixture of these) Aside: do we *really* need this flexibility? It seems to create unnecessary complication for the clients. We can remove it by changing either the Share: MappingPolicy.ID multiplicity to "optional" (0..1) or (Mapping)Policy: UserDomain.ID multiplicity to "required" (1). The former seems the better option (IMHO). We identify which StorageShares are to be used for accounting by selecting only those StorageShares that are published with a SharingID attribute value of "dedicated". The metric values to be used for storage accounting are the attached StorageShareCapacity objects. It might be worth adding another optional attribute, to allow accounting for (temporarily?) off-line storage. For example, adding: UnavaliableSize UInt64 0..1 GB Size of storage extent that is currently unavailable. The WLCG InstalledCapacity would then be: InstalledCapacity = TotalSize + UnavailableSize Cheers, Paul.

2 3

WLCG requirements and use cases for resources installed capacity
by Flavia Donno 17 Dec '08

17 Dec '08

Dear all, in order to fulfill my promise and document the WLCG requirements and usecases for the accounting of the resource installed capacity, I added an item in the wiki page below: http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/HomePa… (under Misc) Is this the right place ? Thanks. Flavia

2 1

today telecon - start at 4 PM CET
by Sergio Andreozzi 15 Dec '08

15 Dec '08

Dear all, I need to postpone the today phonecall to 4 PM CET: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… I apologize for the late notice. Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40127 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

GLUE 1.3 erratum/inconsistency
by Burke, S (Stephen) 11 Dec '08

11 Dec '08

Hi, Another apparent fault in the 1.3 document, with the Preemption attribute. In the CE section it says: Policy.Preemption int32 1 If greater than 0, the batch system enables preemption of jobs; if 0, the batchsystem does not enable preemption of jobs (NN) so the text defines it as an integer even though the meaning is clearly boolean, either jobs may be pre-empted or not. Given that it's stated so explicitly it seems to be intentional, but I don't know why! On the other hand, in the VOView table it says: Policy.Preemption boolean 1 see definition in ComputingElement entity (NN) so there it is defined as boolean even thought it should be identical to the CE attribute. In our actual deployed LDAP schema it seems that it's typed as an integer, and the same definition is used for both CE and VOView. Stephen PS In the GLUE 2 document the corresponding attribute is typed as boolean. -- Scanned by iCritical.

1 0