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
On Friday 11 April 2008 18:17:14 Burke, S (Stephen) wrote:
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.
Agreed.
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.
True, but there's a Nordogrid use-case for recording per-VO space usage info for shared spaces. (this is right, isn't it? I often feel like the only one bringing this one up) [...]
Personally I'm not entirely convinced that the right way to go is to publish shared Shares multiple times [...]
For the most part, I don't mind how things turn out provided they can be mapped to dCache concepts, so I can publish the information. I, too, am concerned that this will balloon the stored data, but I'm happy to go with what everyone else decides is best. Cheers, Paul.
Paul Millar wrote:
True, but there's a Nordogrid use-case for recording per-VO space usage info
NorduGrid. | ^
for shared spaces.
(this is right, isn't it? I often feel like the only one bringing this one up)
Yes, but also for small VOs in EGEE we should ensure that GLUE can tell at least what each VO as a whole is using and what it may have available (with known caveats).
Paul Millar [mailto:paul.millar@desy.de] said:
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.
True, but there's a Nordogrid use-case for recording per-VO space usage info for shared spaces.
(this is right, isn't it? I often feel like the only one bringing this one up)
Yes (and probably not just Nordugrid in fact) - we had another go at this but I'm still not sure we have a conclusion. Basically we have a trade-off, we either have something like the current draft and accept that "shared shares" may result in the same information being published many times, or else we have a more complex schema with a new object, similar to the current separation between SA and VOInfo, which allows the duplicated information to be separated out and published only once. Stephen
Dear Steven, Quota's are not part of LCG/EGEE storage elements, since we have no experience of quota's in these grids I wonder if you will appreciate the Glue standard not matching 100% to what is one day implemented. Unless you have a crystal ball, I would keep away form Quotas in GLue. As for accounting, since the majority of people involved in Glue seem want per VO accounting , we should not treat VO's with attributes such as "worthy" of publishing (HEP) in the Glue standard, just to minimise the consequences. If Stevens concern is warranted, maybe we should have add a special VO concept (a bit like GridPP) for this, to avoid the consequence of "large amount of information being published many times purely to convey one attribute (UsedSize) which varies." which is in effect all supported VO's which are not dedicate space. We should possibly have a second VO concept for publishing VO's like Biomed which are not prepared to acknowledge their resource usage, and prefigure to keep their list of services centrally managed. That's my opinion, we need one maybe two more VO's one for non published resources, used by security conscious VO's (eg biomed), and a potential second one to allow accounting, for shared resources. As you can see this "Requirement" for accounting in GLue makes for complications almost tripling the entities for Glue Storage and now adding 2 new VO's, please tell me if you have a simpler resolution. Owen My opinions, are mine and may or may not be shared with dcache, or of my employer desy.
participants (4)
-
Burke, S (Stephen) -
Maarten Litmaath -
owen.synge＠desy.de -
Paul Millar