- glue-wg - lists.ogf.org

telecon reminder - today - storage - 2 PM CEST
by Sergio Andreozzi 17 Apr '08

17 Apr '08

Dear all, this is a reminder for the today telecon (in 20' minutes). It seems that there are problems with the forge.ogf.org website. The number to call is +41 22 76 77000 (ask for GLUE meeting, contact person: Laurence Field) Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 1

Datastore proposal
by Burke, S (Stephen) 17 Apr '08

17 Apr '08

Hi, I'll do this while it's fresh in my mind ... for those not in the meeting, the background is that we have a long-running debate about whether to represent the storage hardware explicitly in the schema. In the original Glue we had the Storage Library, which we then obsoleted because no-one used it. In the 1.3 discussion there was the proposed Storage Component, which we left out because we didn't get agreement on whether we needed it. Now we have the same discussion coming round again - the current draft has a Storage Resource to describe the software which manages some storage, e.g. Enstore or GPFS, but still nothing to represent the hardware it manages. The problem is that we never seem to have a clear use case that requires a hardware description, but it keeps coming back in discussions, perhaps because it's a natural way to think about storage systems. (Also LCG has specific hardware restrictions, e.g. that Custodial must imply tape storage, which are not mandated by SRM or described in the schema.) My proposal is to shortcut this discussion by putting a simple representation of the hardware in the schema, which would be optional for anyone to publish, so the debate can at least be pushed off to implementation time. I propose an object which I tentatively call a Datastore (or we could go back to the old StorageLibrary name if we want everything to start with "Storage"). A Datastore would represent some set of uniform managed storage hardware, e.g. a tape robot plus all the tapes, or a set of disk servers managed for the same purpose. For clarity, disk servers allocated e.g. to different VOs would still just constitute a single Datastore, but disk servers used for completely different purposes would be separate, e.g. the disk cache in front of the tape robot would be a different Datastore if managed independently of the Disk1 storage. The Datastore would have fairly few attributes: UniqueID (as usual) Name (human-readable name, maybe indicating the technology, e.g. StorageTek) Type (disk, tape, ... - open enumeration) Capacity (NB this is in the schema as a separate object for technical reasons but is really just an attribute) OtherInfo (as usual) It might perhaps be useful to give the technology, e.g. RAIDn for disk systems, but I think that should go in OtherInfo as it's likely to be hard to standardise it. This would be linked to the existing StorageResource object with a one-to-many relation, i.e. one Resource could manage many Datastores (Castor manages tape and disk) but not vice versa, one Datastore can only be managed by one Resource - if there are e.g. multiple sets of disk servers managed by several different software systems that would constitute multiple Datastores. The relation to StorageEnvironment and/or StorageShare remains open for discussion as there are other issues there (e.g. whether we want the Environment at all), but conceptually you would want a relation between the Share and whichever DataStore(s) store the data for that Share. That can be one to many, e.g. if Custodial/Online uses disk+tape, as in WLCG. Comments? Stephen

7 31

Updated thoughts...
by Paul Millar 16 Apr '08

16 Apr '08

Hi all, I've tried updated the storage objects "thoughts" document with feedback from people. (Jen, my apologies, I now see what you meant about covering sets: we share the same understanding but what I had written was just wrong .. I've tried to get it more right this time). Sorry if I've missed out someone's a comment, please yell. Also, I've tried to separate the more informative paragraphs by marking them differently. One way of using this information would be to fold the more normative parts into the GLUE spec proper. The informative paragraphs could then form an informative annex to the document; c.f. http://standards.ieee.org/guides/companion/part1.html#annexes Cheers, Paul. --- Some thoughts on GLUE Storage objects (v0.2) --- These are some notes on the different objects in the forthcoming GLUE v2.0 information model, concentrating on those responsible for storage. These notes provide a mixture of normative and informative information. The non-normative (informative) paragraphs are red-lined (marked with a "|" on the left-most edge). This should be read with the GLUE schema and, if there are any discrepancies, the GLUE schema document is authoritative. Please email corrections to <paul.millar(a)desy.de> or the GLUE working group <glue-wg(a)ogf.org>. UserDomain: A collection of one or more end-users. All end-users that interact with the physical storage are a member of a UserDomain. [much more can (and perhaps should) be said here] | A Virtual Organisation (VO) is an instance of a UserDomain. A group | within a VO may be represented as a UserDomain. In general, users | derive their authorisation from their membership. StorageCapacity: A StorageCapacity object describes the ability to store data within a homogeneous storage technology. Each object provides a view of that physical storage medium with a common access latency. All StorageCapacity objects are specified within a certain context. The context is determined by an association between the StorageCapacity object and precisely one other higher-level object. | These associations are not listed here, but are described in later | sections. | | In general, a StorageCapacity object will record some | context-specific information. Examples of such information include | the total storage capacity of the underlying technology and how much | of that total has been used. | | The underlying storage technology may affect which of the | context-specific attributes are available. For example, tape storage | may be considered semi-infinite, so the total and free attributes have | no meaning. If this is so, then it affects all StorageCapacity objects with | the same underlying technology, independent of their context. | | Different contexts may also affect what context-specific attributes | are recorded. This is a policy decision when implementing GLUE, as | recording all possible information may be costly and provide no great | benefit. | | [Aside: these two reasons are why many of the attributes within | StorageCapacity are optional. Rather than explicitly subclassing | the objects and making the values required, it is left deliberately | vague which attributes are published.] | | A StorageCapacity may represent a logical aggregation of multiple | underlying storage technology instances; for example, a | StorageCapacity might represent many disk storage nodes, or many | tapes stored within a tape silo. GLUE makes no effort to record | information at this deeper level; but by not doing so, it requires | that the underlying storage technology be homogeneous. Homogeneous | means that the underlying storage technology is either identical or | sufficiently similar that the differences don't matter. | | In most cases, the homogeneity is fairly obvious (e.g., tape storage | vs disk-based storage), but there may be times where this distinction | becomes contentious and judgement may be required; for example, | the quality of disk-base storage might indicate that one subset is | useful for a higher-quality service. If this is so, then it may make | sense to represent the different class of disk by different | SpaceCapacities. StorageEnvironment: A StorageEnvironment is a collection of one or more StorageCapacities with a set of associated (enforced) storage management policies. | Examples of these policies are Type (Volatile, Durable, Permanent) | and RetentionPolicy (Custodial, Output, Replica). | | In general, a StorageEnvironment may have one or more | RetentionPolicy values. If it has more than one, all data stored | using this StorageEnvironment will adopt precisely one of the values | present. The policy describing how data is assigned a | RetentionPolicy value is not specified; for example, GLUE does not | record a default RetentionPolicy. GLUE also does not specify | whether it is possible to migrate data from one RetentionPolicy | value to a different value whilst using the same | StorageEnvirionment. StorageEnvironments act as a logical aggregation of StorageCapacities, so each StorageEnvironment must have at least one associated StorageCapacity. | It is the associated StorageCapacities that allow a | StorageEnvironment to store data with its advertised policies; for | example, to act as (Permanent, Custodial) storage of data. | | Since a StorageEnvironment may contain multiple StorageCapacities, | it may describe a heterogeneous environment. An example of this is | "tape storage", which has both tape back-end and disk front-end into | which users can pin files. Such a StorageEnvironment would have two | associated StorageCapacities: one describing the disk storage and | another describing the tape. If a StorageCapacity is associated with a StorageEnvironment, it is associated with only one. A StorageCapacity may not be shared between different StorageEnvironments. | StorageCapacities associated with a StorageEnvironment must be | non-overlapping with any other such StorageCapacity and the set of | all such StorageCapacities must represent the complete storage | available to end-users. Each physical storage device (e.g., | individual disk drive or tape) that an end-user can utilise must be | represented by (some part of) precisely one StorageCapacity | associated with a StorageEnvironment. | | Nevertheless, the StorageCapacities associated with | StorageEnvironments may be incomplete as a site may deploy physical | storage devices that are not directly under end-user control; for | example, disk storage used to cache incoming transfers. GLUE makes | no effort to record information about such storage. StorageResource: A StorageResource is a logically separable component that provides the management functionality described in one or more StorageEnvironments. More than one StorageResource may cooperate to provide an advertised StorageEnvironment. | Typically, a StorageResource will describe a running instance of | some software, but it may describe some commodity hardware. A | StorageResource should, under normal circumstances, have at least | one StorageEnvironment, otherwise there wouldn't be much point | publishing information about it. | | All StorageEnvironments must be part of at least one StorageResource | as the StorageResource is how the management attributes described in | the StorageResource are provided. | | GLUE makes no attempt to record which physical storage (as | represented by StorageCapacity objects) is under control of which | StorageResource. StorageShare: A StorageShare is a logical partitioning of one or more StorageEnvironments. | Perhaps the simplest example of a StorageShare is one associated | with a single StorageEnvironment with a single associated | StorageCapacity, and that represents all the available storage of | that StorageCapacity. An example of a storage that could be | represented by this trivial StorageShare is the classic-SE. StorageShare must have one or more associated StorageCapacities. These StorageCapacities provide a view of the different homogeneous underlying technologies that are available under the space. | The StorageCapacities within the StorageShare context need not | describe all storage: the number of StorageCapacities associated | with a StorageShare may be less than the sum of the number of | StorageCapacities associated with each of the StorageShare's | associated StorageEnvironments. | | There is an *implicit* association between the StorageCapacity | associated with a StorageShare and the corresponding StorageCapacity | associated with a StorageEnvironment. Intuitively, this association | is from the fact that the two StorageCapacities are views of the | same underlying physical storage. This implicit association is not | recorded in GLUE. | | Any pair of StorageShares may be (pair-wise) overlapping; that is, | they have at least one pair of implicitly associated | StorageCapacities (both within a different StorageShare context) | that provide a view onto the a common portion of underlying storage. | A pair of shared StorageCapacities indicate common access to a | shared underlying storage and, in general, storage operations within | one shared StorageShare will affect the other. | | A pair of StorageShares may be partially shared, that is, they have | at least one pair StorageCapacities that are shared and at least one | that is not. Partially shared StorageCapacities could represent two | UserDomain's access to a tape store, where they share a common set | of disk pools but the tape storage is distinct. | | StorageShares may covering or not. A covering set of StorageShares | will make all of the underlying storage available to the end-users. | When a set of StorageShares are not covering, the site-admin has | refrained from allocating some of the underlying storage. | In general, given a StorageCapacity (SC_E) that is associated with | some StorageEnvironment and which has totalSize TS_E, let TS_S be | the sum of the totalSize attributes for all StorageCapacities that | are: | | 1. associated with a StorageShare, and | 2. that are implicitly associated with SC_E. | | If the StorageShares are covering and non-overlapping then TS_S = | TS_E. If they are covering and overlapping the TS_S > TS_E. If they | are not covering and non-overlapping, then TS_S < TS_E. If they are | not covering and overlapping no general statement can be made about | the totalSize. | | End-users within a UserDomain may wish to store or retrieve files. | The StorageShares provides a complete, abstract description of the | underlying storage at their disposal. No member of a UserDomain may | interact with the physical hardware except through a StorageShare. | | In general, one should not draw strong conclusions about how these | attributes will alter under storage operations. The behaviour of | these attribtues may be governed by site level policies, software | implementation, underlying storage technology, concurrent usage, | etc; for example, deleting files may or may not result in freeSpace | increasing. | | A grid may impose more strict requirements on the attributes | behavior. This may be due to good knowledge of deployed software, | management policies and underlying technologies in used. Care | should be taken when sharing monitoring information that the storage | models are compatible. | | A single StorageShare may allow multiple UserDomains to access | storage; if so, the StorageShare is "shared" between the different | UserDomains. Such a shared StorageShare is typical if a site | provides storage described by the trivial StorageShare (one that | covers a complete StorageEnvironment) whilst supporting multiple | UserDomains. StorageMappingPolicy: The StorageMappingPolicy describes how a particular UserDomain is allowed to access a particular StorageShare. | No member of a UserDomain may interact with a StorageShare except as | described by a StorageMappingPolicy. | | The StorageMappingPolicies may contain information that is specific | to that UserDomain, such as one or more associated | StorageCapacities. If provided, these provide a UserDomain-specific | view of their usage of the underlying physical storage technology as | a result of their usage within the StorageShare. | | If StorageCapacities are available with a StorageMappingPolicy | context, there may be the same number as are associated with the | corresponding StorageShare or less. StorageEndpoint: A StorageEndpoint specifies that storage may be controlled through a particular interface. | In general, such interfaces do not allow data transfer. The SRM | protocol is an example of such an interface and a StorageEndpoint | would be advertised for each instance of SRM. | | The access policies describing which users of a UserDomain may use | the StorageEndpoint are not published. On observing that a site | publishes a StorageEndpoint, one may deduce only that it is valid | for at least one user of one supported UserDomain. StorageAccessProtocol: A StorageAccessProtocol describes one method by which end-users may sent data to be stored, received stored data, or undertake both operations. | Access to the interface may be localised; that is, only available | from certain computers. It may also be restricted to specified | UserDomains. However, neither policy restrictions are published in | GLUE. On observing a StorageAccessProcol, one may deduce only that | it is valid for at least one user of one supported UserDomain from | at least one computer. StorageService: A StorageService is an aggregation of StorageEndpoints, StorageAccessProtocols and StorageResources. | It is the top-level description of the ability to transfer files to | and from a site, and manipulate the files once stored.

6 15

RetentionPolicy definitions
by Maarten Litmaath 16 Apr '08

16 Apr '08

Hi all, the SRM v2.2 docs are here: http://sdm.lbl.gov/srm-wg/ Quoting from that, with adjustments: --------------------------------------------------------------- The Retention Policy represents the quality of retention, which indicates the probability of the storage system losing a file. Replica quality has the highest probability of loss, but is appropriate for data for which a certain amount of loss can be tolerated, in particular when other copies can be accessed in a timely fashion. Output quality is an intermediate level and is appropriate for data which can be replaced by lengthy or effort-full processes. Custodial quality corresponds to low probability of loss. --------------------------------------------------------------- Thanks, Maarten

4 10

Roadmap towards public comment of GLUE 2.0 Specification
by Sergio Andreozzi 15 Apr '08

15 Apr '08

Dear all, today we refined the roadmap towards the public comment of the GLUE 2.0 Specification. This is an important milestone for our group and I recommend everybody to mark this in the agenda: * 25 Apr 2008: o Final WG agreement on Computing and Storage * 9 May 2008: o editorial cleaning of the document and integration of the reference renderings in the appendix * 12-17 May 2008: o WG last call period * 19 May 2008: o submission to OGF Editor for public comment - hard deadline We should do our best to meet this in order to have GLUE 2.0 in public comments by OGF 23 and as proposed recommendation for OGF 24. Given the status of the spec, if we maintain the current level of participation, I believe that we can meet this deadline. Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

Quotas and accounting
by Burke, S (Stephen) 15 Apr '08

15 Apr '08

Hi, Expanding on a couple of the things from today's meeting ... on quotas my feeling is that we should just ignore them for the time being. We currently have no quota system anyway, and to represent one we would be likely to need some dedicated attributes/objects, I don't think we should try to force it in to existing things, e.g. restricting the FreeSize. Apart from anything else the quotas could well operate at a different level from the MappingPolicy, e.g. maybe that just says VO:atlas but the quotas are implemented per group, or even per user. Also quotas are often over-allocated so you lose the normalisation. On accounting, I think we should be careful that it isn't a main objective for Glue, and we can't possibly hope to do detailed accounting. However, on the specific question of publishing a per-VO UsedSize for Shares which are shared between VOs it does seem like something we should try to meet. Personally I'm not entirely convinced that the right way to go is to publish shared Shares multiple times - it results in a large amount of information being published many times purely to convey one attribute (UsedSize) which varies. However, I'll wait to have a look at the updated draft and then see if I think there's a simple alternative - I agree that technically the proposal should work as long as you can tell which Shares are shared. Stephen

4 4

DENY rules
by Burke, S (Stephen) 15 Apr '08

15 Apr '08

Hi, Just as a comment on the discussion about DENY rules in policies, my alternative suggestion was to have "allow" rules with a more complex syntax, e.g. something like: VOMS:/atlas/*:EXCEPT:/atlas/higgs which would match against any subgroup of atlas except higgs. That would be a bit harder to parse, but maybe still easier than a generic DENY rule. Stephen

5 22

modelling users
by Timo Baur 15 Apr '08

15 Apr '08

Hi list, in order to map running Globus-jobs to VOs, we now try to model user information with GLUE 2.0. From GRAM-Audit, we get (local user id, user DN, job). From another source, we will hopefully get (user DN, user name, VO). Should we best encode the user information in an composed UserDomain like UserDomain (Name: VO) composed by UserDomain(UniqueID: user DN, name: user name) or is there another solution ? Does anybody think it would make sense to introduce an additional or specialized entity for users ? Cheers, Timo -- Dipl-Inf. Timo Baur Leibniz Rechenzentrum Kommunikationsnetze/Netzplanung Boltzmannstr. 1 D-85748 Garching Telefon +49 89 35831-8729 Fax +49 89 35831-5729 timo.baur(a)lrz-muenchen.de

3 4

Update of relational rendering of Glue 2.0 draft 33
by Felix Nikolaus Ehm 15 Apr '08

15 Apr '08

Dear all, please find the latest rendering for the relational model (ref 33) here: https://twiki.cern.ch/twiki/bin/view/EGEE/ExampleGlue20SQL Unfortunatly, I didn't find time to update the examples on the page - but its on my list. Comments/Questions are appreciated. Cheers, Felix --- Felix Ehm IT-GD tel : +41 22 7674580 CERN, Switzerland -----------------------------------------

2 4

Next telecon: 15 Apr - 4 PM CEST - Implementation
by Sergio Andreozzi 14 Apr '08

14 Apr '08

Dear all, I'm summarizing the next telecons: # 15 Apr 2008 - 4 PM CEST - 1,5h - implementation # 17 Apr 2008 - 2 PM CEST - 1,5h - storage # 21 Apr 2008 - 2 PM CEST - 1,5h - computing Talking to you tomorrow at 4 PM CEST Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0