Hi all, I don't know if anyone has been looking at this, but there's an emerging standard (through DMTF) in modelling "things" (computer-hardware and -software, network equipment, etc): CIM. There seems to be some cross-over here through OGF, so forgive me if this is already "well known". Anyway, for those who haven't heard of them, their schema makes for interesting reading. The current version (2.18) is available from: http://www.dmtf.org/standards/cim/cim_schema_v218 "Device" (from which a StorageDevice may be published) http://www.dmtf.org/standards/cim/cim_schema_v28/CIM_Device28-Final.pdf How to publish ACLs: http://www.dmtf.org/standards/cim/cim_schema_v218/CIM_Policy.pdf Enjoy! Paul.
Carl Kesselmann made us aware of this in the very first days of GLUE. I believe Glue copied some parts of their schema where appropriate. I don't know how much we might have diverged since then. John
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar Sent: 28 April 2008 17:40 To: GLUE WG Subject: [glue-wg] Comparison with CIM
Hi all,
I don't know if anyone has been looking at this, but there's an emerging standard (through DMTF) in modelling "things" (computer-hardware and -software, network equipment, etc): CIM. There seems to be some cross-over here through OGF, so forgive me if this is already "well known".
Anyway, for those who haven't heard of them, their schema makes for interesting reading. The current version (2.18) is available from: http://www.dmtf.org/standards/cim/cim_schema_v218
"Device" (from which a StorageDevice may be published)
http://www.dmtf.org/standards/cim/cim_schema_v28/CIM_Device28- Final.pdf
How to publish ACLs:
http://www.dmtf.org/standards/cim/cim_schema_v218/CIM_Policy.pdf
Enjoy!
Paul. _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Hi Paul, CIM has been on the radar ever since the start and has never really left it. Within the OGF there are number of DMTF representatives and one, Ellen Stokes from IBM, is a member of this working group. Although not in the working group charter, one of the aims is to render Glue using CIM in order to make an OGF vendor extension to the CIM schema. Sergio may correct me if I am wrong but he is intending to write some CIM information providers for Open Pegasus to publish information related to grid services. Whenever we have had questions, such as what is the syntax for expressing the OS, we investigate the solution first in CIM. However, for all the details it sometimes misses quite a few helpful things. :) Both myself and Sergio have attended DMTF meetings to discuss our mutual needs and to gain some experience on the respective environments. CIM is excels at describing detailed information about hardware resources and setup of a data center but it is weak when it comes to software life cycle management and abstract services. Paul Strong from e-bay is pushing the software life cycle management part in the reference model working group and we are essentially looking at the abstract grid services. If the Glue schema becomes on OGF recommendation and we make a vendor extension to the CIM schema, the DMTF representatives will most probably take this to the DMTF to find out what the next steps should be and if this is relevant to a wider community. The Storage Networking Industry Association (SNIA) is a member of the DMTF and probably has something to do with StorageDevice schema. When starting this group we tried to find someone from SNIA to participle. After some initial interest, we did not manage to find anyone who could spare the time. If you think it might be helpful to get someone involved, I can fish out the details from my email archive and chase this up. From looking at the UML, I am a little unsure of how this helps in the discussion. Please could you explain in more detail why this is relevant? btw, I notice that as MediaAccesssDrives: 1) They have CDROMDrive and DVDDrive with out sub classing from OpticalDrive. 2) They are missing both SolidStateDrive and Holographic Drive 3) They do get extra points for a Worm Drive but lose some for the missing Warp Drive :) Laurence Paul Millar wrote:
Hi all,
I don't know if anyone has been looking at this, but there's an emerging standard (through DMTF) in modelling "things" (computer-hardware and -software, network equipment, etc): CIM. There seems to be some cross-over here through OGF, so forgive me if this is already "well known".
Anyway, for those who haven't heard of them, their schema makes for interesting reading. The current version (2.18) is available from: http://www.dmtf.org/standards/cim/cim_schema_v218
"Device" (from which a StorageDevice may be published)
http://www.dmtf.org/standards/cim/cim_schema_v28/CIM_Device28-Final.pdf
How to publish ACLs:
http://www.dmtf.org/standards/cim/cim_schema_v218/CIM_Policy.pdf
Enjoy!
Paul. _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Hi John, Laurence, others Thanks for all the info: that's helped set GLUE in the wider context. Perhaps we could add this as a FAQ entry somewhere? A "links with industry" entry always looks good, I guess. On Monday 28 April 2008 21:39:40 Laurence Field wrote: [many things, but ruthlessly culled]
Sergio may correct me if I am wrong but he is intending to write some CIM information providers for Open Pegasus to publish information related to grid services.
This would be through WBEM, right? From what I've seen, I believe there's a few high-level (Enterprise) projects that (are purported to) use WBEM under the hood, whether this is using WS-Man(agement) or CIM/HTTP as a transport/session, I'm not sure. I'm also not sure whether their support is for only a subset of the CIM schema, or whether it's "generic", so the same software could monitor (and control?) grid applications. Which reminds me: is there any tie-in with the GridCC project? From their FAQ: "Why do I need GRIDCC? "[...] if you want to use a multi-user/multi-site interactive monitoring and control environment then GRIDCC software may be what you are looking for." Sorry, I'm still figuring out how all these pieces fit together!
[...] However, for all the details it sometimes misses quite a few helpful things. :)
As is the way of things, I guess ;-) [...]
If the Glue schema becomes on OGF recommendation and we make a vendor extension to the CIM schema, the DMTF representatives will most probably take this to the DMTF to find out what the next steps should be and if this is relevant to a wider community.
Ah, excellent.
The Storage Networking Industry Association (SNIA) is a member of the DMTF [...] If you think it might be helpful to get someone [from SNIA] involved, I can fish out the details from my email archive and chase this up.
Well, SNIA is another name I've heard of, but with respect to some different projects: XAM and SMI-S (although, I have only a little detailed knowledge of both) http://www.snia.org/forums/xam/ http://www.snia.org/smi/home XAM is quite interesting having some features similar to SRM (but somewhat lower-level). They've initially gone for an API-based standard (leaving the wire-protocol vendor-specific), but I believe they may eventually standardise on a wire-protocol, too. That said, I'm not sure how much momentum XAM has currently, or what is the support for current hardware. From a dCache perspective, investigating this further is a back-burner project, but the SNIA XAM people might be interested in looking at GLUE Storage entities, or maybe not: it could be too low-level. SMI-S seems to build on CIM/WBEM to provide/enhance the support for managing distributed storage. I guess there's some overlap between this and the GLUE storage entities. So, getting in touch with SNIA might be useful. I suspect that having people with an alternative view-point look at GLUE would benefit GLUE in the long-run, but would be inventing more work for ourselves in the short-term :-/
From looking at the UML, I am a little unsure of how this helps in the discussion. Please could you explain in more detail why this is relevant?
Well, there was a few fairly general things, mostly from the "being informed from:" category (my apologies if this is already widely known): First, I was (in a naive way) a little concerned that the DMTF/CIM (with SNIA /SMI-S) people might be working in isolation and (to some extent) duplicating the work in GLUE. It's good to hear that people in GLUE/OGF and both DMTF SNIA are aware of each other. Second, CIM seems to have the concept of logically partitioning part of some physical medium and making it available (page 14, StorageExtent), which seems roughly analogous to our original (VO-view independent) idea of a StorageSpace. For example, it's interesting to see how CIM-Schema would model a D1T1 space. I think it would be modeled as a CompositeExtent (a subclass of StorageExtent), which has two StorageExtents: one a DiskPartition (or possibly a LogicalDisk, should we wanted to model the disk-pools too) and a TapePartition. Third, given our discussion on "describing the hardware"; or rather, describing some abstraction of the hardware. We can look at what abstraction might make sense from a CIM point-of-view rather than our own ad-hoc abstraction. It's perhaps interesting that the next layer of abstraction (see page 13) from MediaAccessDevice is LogicalDevice, which combines real physical hardware with the StorageExtent concept. So, our abstracted hardware (a Datastore) would be represented, under CIM-Schema, as a LogicalDisk (a subclass of StorageExtent, itself a subclass of LogicalDevice) that is associated with multiple MediaPartitions (either DiskPartitions or TapePartitions) of a "sufficiently similar" type. Finally, there's also discussion on how to represent ACLs and policies. Again, we could probably "be informed by" CIM's approach here. I doubt anyone writing an info provider will have sufficient time to implement and test that they conform to CIM-Schema approach, let alone the information consumer figuring out what to make of all this information. My view is GLUE simply shouldn't publish any ACL information: a simple link from UserDomain to the objects that UserDomain might interact with should be sufficient, right? At worse, people try a service and find out they're not authorised (which is an inevitable possibility, as GLUE can never publish all ACEs). Also, just as a general comment, I think GLUE's doing reasonably well at keeping things simple, when compared to CIM's schema :-)
I notice that as MediaAccesssDrives:
1) They have CDROMDrive and DVDDrive with out sub classing from OpticalDrive.
Aye, but there's (apparently) nothing they share beyond both being a MediaAccessDevice: their "opticalness" is abstracted out by the interface, I guess.
2) They are missing both SolidStateDrive and Holographic Drive
Yup, although to be fair, it was only you mentioning the holo-drives that I'd heard of them being commercially available (last I heard, they were vapourwear).
3) They do get extra points for a Worm Drive but lose some for the missing Warp Drive
True. Cheers, Paul.
Hi Paul, I think that Open Pegasus is actually a CIMOM and to be classified as a WBEM it has to use CIM-XML over HTTP, but I this is a minor detail which depends on the version. Implementations of the CIMOM have been around or a long time, I think you could even get it as a download for Windows 95! Some time ago I conducted an investigation on the potential for using this to replace the GRIS. The results are documented here if you are interested. http://twiki.cern.ch/twiki/bin/view/EGEE/ProviderSpecification There are a few features that were missing at the time, the main one being a caching mechanism to avoid to many queries throttling the resource. It is important to understand the different in between aim of the DMTF and our aims. The DMTF is primarily concerned about management and this is the view from a service providers perspective, we are interested in the service from a consumers perspective. Paul Strong keeps showing a slide when talking about the reference model group of an "e-bookstore". This shows all the things that it takes to provide an e-bookstore such as database services, web servers, load balancers etc. This is what he wants to model, his data center, so that the management can be automated. For me this slide is only half the story, as users and higher level services, we are wanting to automate the use of the e-bookstore. We don't care how the services is provided, what we care about is things like; what kind of store is this?, what is the URL I use to interact with it?, can I pay with Pay Pal?, How long will it take to ship?, etc. It might be useful if we agreed on main entities such as books and payment :) however, the information model for these entities could be significantly different. We have had a few discussions with people who are involved in SNIA but it hasn't really been very fruitful. I think it might just be that we are working in slightly different problems domains, provider vs consumer, and we don't really have spare capacity (sorry for the pun), to investigate further. Last year we did discuss the possibility of Felix going to a SNIA meeting in Germany but for some reason it didn't work out. Do you know if any of the dcache team have are involved with SNIA at any level?
My view is GLUE simply shouldn't publish any ACL information: a simple link from UserDomain to the objects that UserDomain might interact with should be sufficient, right? At worse, people try a service and find out they're not authorised (which is an inevitable possibility, as GLUE can never publish all ACEs).
I kind of agree with this but it is such a huge architectural change that it can't be done on a short timescale.
Also, just as a general comment, I think GLUE's doing reasonably well at keeping things simple, when compared to CIM's schema :-)
People usually get scared with CIM as they see the whole schema. What usually happens is that you take a profile which only uses the bits you really need. I guess the provider vs consumer differences means that the consumer schema should always be simpler. Laurence
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: My view is GLUE simply shouldn't publish any ACL information: a simple link from UserDomain to the objects that UserDomain might interact with should be sufficient, right? At worse, people try a service and find out they're not authorised (which is an inevitable possibility, as GLUE can never publish all ACEs).
I think a key point in all these discussions is to remember that we're always striking a balance, and practicality is more important than purity. It's certainly true that we can't publish all ACLs at an arbitrary level of detail. On the other hand the main purpose of GLUE is to allow a client to prune the range of resources it has to deal with - if you have to contact 500 services to find the one that authorises you then you probably have a problem. I think the way to deal with that is for the schema to define the format, and individual grids can then decide what level of detail is needed for their community. Stephen
On Tue, 29 Apr 2008 17:07:03 +0100 "Burke, S (Stephen)" <S.Burke@rl.ac.uk> wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: My view is GLUE simply shouldn't publish any ACL information: a simple link from UserDomain to the objects that UserDomain might interact with should be sufficient, right? At worse, people try a service and find out they're not authorised (which is an inevitable possibility, as GLUE can never publish all ACEs).
Dear Steven,
I think a key point in all these discussions is to remember that we're always striking a balance, and practicality is more important than purity.
On this issue I agree, but I disagree with you suggesting that we represent standard ACL's and leave out Castor and DPM due to the low level of storage deployment they have compared to dCache. I think if VO's if they set ACL's will be aware of what they set and all they need to know is if a service is up and how to write to it. Can you please explain why more is needed for Glue?
It's certainly true that we can't publish all ACLs at an arbitrary level of detail. On the other hand the main purpose of GLUE is to allow a client to prune the range of resources it has to deal with - if you have to contact 500 services to find the one that authorises you then you probably have a problem.
I quite agree, this is why we publish VO as an attribute to entities. To supplement this we can discover the implementation of a service and its version number. From this we can inquire the access and publish it at a VO level.
I think the way to deal with that is for the schema to define the format, and individual grids can then decide what level of detail is needed for their community.
I assume you mean ACL's. Provided you have an answer why VO's will need ACL's published is it wise to couple our selves to the dCache implementations so preventing future enhancements to the ACL model by Storm, Castor or DPM, and forcing them to comply to dCache? Storm, DPM and Castor that together make up 1/3 of the storage in wLCG and should not be overlooked. NorduGrid and OSG do not use these minority storage elements but I should not like wLCG to be damaged by Glue turning into a requirements source, just for a desire for standardisation on the cross product of VO specific settings and service implementation on Castor's already overstretched support teams when Nordu Grid and OSG impose a dCache implementation of ACL's. Regards Owen Synge
Owen Synge [mailto:owen.synge@desy.de] said:
On this issue I agree, but I disagree with you suggesting that we represent standard ACL's and leave out Castor and DPM due to the low level of storage deployment they have compared to dCache.
I didn't say anything about specific implementations. My point is that GLUE is about interoperability, and if the underlying middleware isn't interoperable then GLUE can't do much about it. To the extent that it is interoperable, e.g. in LCG via the SRM MOU, we then have a question about how much of that needs to be advertised in GLUE.
I think if VO's if they set ACL's will be aware of what they set and all they need to know is if a service is up and how to write to it.
Can you please explain why more is needed for Glue?
In practice it doesn't work like that. For example, sites may set up their CEs to give priority to particular groups within a VO, so a user needs a view of the system which relates to the share of resources they will get mapped to. In general the VO users aren't aware of how all the sites are configured, and in any case you also need to know the dynamic state, e.g. how many jobs are in fact running for each group. Hence we have a use case to publish Shares with an ACL to say which users are authorised to use which Shares. For storage the analogue is to know whether there is a Share (space) which you are authorised to write to, and if there is whether it has enough free space to store your data. What is not so clear to me is whether we have a use case to publish more detailed authorisation - i.e. a situation where you know you are authorised and there is enough space, but you need to discover exactly where in the namespace you should be writing.
I assume you mean ACL's. Provided you have an answer why VO's will need ACL's published is it wise to couple our selves to the dCache implementations so preventing future enhancements to the ACL model by Storm, Castor or DPM, and forcing them to comply to dCache?
As I say, I didn't say anything about dcache specifically. From a purely LCG/EGEE perspective it's actually the DPM authorisation model we would like to have and dcache and castor should come in line. For GLUE it doesn't really matter, we just define an abstract format which can (hopefully) be specialised according to the needs of particular grids. However, it seems that the lack of convergence in authz models has pushed LCG into asking to have two separate kinds of authz (on namespaces and space tokens) and that does need to be considered for GLUE because it would affect the model, e.g. Flavia's proposal to have a new object for namespaces.
I should not like wLCG to be damaged by Glue turning into a requirements source,
As far as I'm concerned it's the other way around, my primary interest is in LCG/EGEE and I want to try to ensure that GLUE can represent the important use cases for that community. If other communities want different things I think it's up to them to make sure they get considered. Stephen
On Thu, 1 May 2008 11:52:23 +0100 "Burke, S (Stephen)" <S.Burke@rl.ac.uk> wrote:
Owen Synge [mailto:owen.synge@desy.de] said:
On this issue I agree, but I disagree with you suggesting that we represent standard ACL's and leave out Castor and DPM due to the low level of storage deployment they have compared to dCache.
I didn't say anything about specific implementations. My point is that GLUE is about interoperability, and if the underlying middleware isn't interoperable then GLUE can't do much about it. To the extent that it is interoperable, e.g. in LCG via the SRM MOU, we then have a question about how much of that needs to be advertised in GLUE.
Im glad you agree, I only picked an implementation that seemed clearly the most logical for the purposes of clarification.
I think if VO's if they set ACL's will be aware of what they set and all they need to know is if a service is up and how to write to it.
Can you please explain why more is needed for Glue?
In practice it doesn't work like that. For example, sites may set up their CEs to give priority to particular groups within a VO, so a user needs a view of the system which relates to the share of resources they will get mapped to. In general the VO users aren't aware of how all the sites are configured, and in any case you also need to know the dynamic state, e.g. how many jobs are in fact running for each group. Hence we have a use case to publish Shares with an ACL to say which users are authorised to use which Shares. For storage the analogue is to know whether there is a Share (space) which you are authorised to write to, and if there is whether it has enough free space to store your data. What is not so clear to me is whether we have a use case to publish more detailed authorisation - i.e. a situation where you know you are authorised and there is enough space, but you need to discover exactly where in the namespace you should be writing.
Thankyou for explaining, but Im still confused why this should be in GLUE, when its dependent on who reads the ACL. ACL's are not static (which Glue is designed for). ACL's may be private (which Glue is not for). Experiments have the Freedom of choice project to say where they want to write.
I assume you mean ACL's. Provided you have an answer why VO's will need ACL's published is it wise to couple our selves to the dCache implementations so preventing future enhancements to the ACL model by Storm, Castor or DPM, and forcing them to comply to dCache?
As I say, I didn't say anything about dcache specifically. From a purely LCG/EGEE perspective it's actually the DPM authorisation model we would like to have and dcache and castor should come in line.
This is a mater of opinion, I suggest prime mover advantage is important but not the only factor in desiding.
For GLUE it doesn't really matter, we just define an abstract format which can (hopefully) be specialised according to the needs of particular grids.
I still feel ACL's are wrong in GLUE for many reasons but I am very pleased that you should think this way.
However, it seems that the lack of convergence in authz models has pushed LCG into asking to have two separate kinds of authz (on namespaces and space tokens) and that does need to be considered for GLUE because it would affect the model, e.g. Flavia's proposal to have a new object for namespaces.
I feel my proposal for VO-Objects and specialisations target at services and VO's appeals more and more.
I should not like wLCG to be damaged by Glue turning into a requirements source,
As far as I'm concerned it's the other way around, my primary interest is in LCG/EGEE and I want to try to ensure that GLUE can represent the important use cases for that community. If other communities want different things I think it's up to them to make sure they get considered.
Just because I oppose the complete idea of ACL's in Glue specifically does not imply I don't think that experiments should and need to get their job done. I am wanting us to do a good job to satisfy wLCG, I think though sometimes wLCG as a collective does a bad job at service decomposition, I often blame myself for backing down too often when I see us making mistakes just because I'm in a minority. I just want to throw out some things from GLUE as I see that they are misplaced, and better solutions exist, FOC (Or a second schema) being a better place for storing what we want to know in this case, which is not ACL's, but where a particular experiment can store data. Regards Owen Synge
owen.synge@desy.de [mailto:owen.synge@desy.de] said:
Thankyou for explaining, but Im still confused why this should be in GLUE, when its dependent on who reads the ACL.
ACL's are not static (which Glue is designed for).
I don't agree with either of those. ACLs are pretty static, they might change on a timescale of weeks, and in any case GLUE is designed for dynamic data, at least down to a timescale of a few minutes.
ACL's may be private (which Glue is not for).
Privacy is up to an implementation. The BDII has no way to keep information private, which may be problematic in various cases, but other implementations may well have access control.
Experiments have the Freedom of choice project to say where they want to write.
That's nothing to do with GLUE per se. FoC is not a project, it's a rather hacky solution to a specific problem and is also specific to EGEE and to the BDII. And apart from that, the current implementation works by editing the ACL on the CE, so it's hardly an argument for not having ACLs!
From a purely
LCG/EGEE perspective it's actually the DPM authorisation model we would like to have and dcache and castor should come in line. This is a mater of opinion, I suggest prime mover advantage is important but not the only factor in desiding.
It's not my decision to make, but it was the decision of the recent EGEE authz working group: https://edms.cern.ch/document/887174/1 (Recommendations document, rec. 12).
I feel my proposal for VO-Objects and specialisations target at services and VO's appeals more and more.
Frankly it's irrelevant to the current discussion, glue 2 is now basically fixed and we aren't going to make any fundamental changes at this stage. Stephen
From: Owen Synge <owen@alice-dsl.de> To: "owen.synge@desy.de" <owen.synge@desy.de> Subject: Still No use case for ACL's? Leading to new questions. Date: Wed, 7 May 2008 23:29:59 +0200 X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) On Wed, 7 May 2008 14:18:57 +0100 "Burke, S (Stephen)" <S.Burke@rl.ac.uk> wrote: Dear Steven, You still have not provided a use case for ACL's on storage areas within GLUE not satisfied by "Freedom of choice" schema could you please present one?
owen.synge@desy.de [mailto:owen.synge@desy.de] said:
Thankyou for explaining, but Im still confused why this should be in GLUE, when its dependent on who reads the ACL.
ACL's are not static (which Glue is designed for).
I don't agree with either of those. ACLs are pretty static, they might change on a timescale of weeks,
ACL's on storage areas can be changed by users at any time they wish how ever often they wish.
and in any case GLUE is designed for dynamic data, at least down to a timescale of a few minutes.
I don't believe current implantation's of GLUE are just not as fast as you suggest. GLUE is about service discovery, I suppose in a purist sense this is dynamic, but its not through intention of GLUE representation providers.
ACL's may be private (which Glue is not for).
Privacy is up to an implementation.
No its an ACL option selected by a user, hence can be changed at any time.
The BDII has no way to keep information private, which may be problematic in various cases, but other implementations may well have access control.
Agreed, BDII is limited in this respect. LDAP can be secured as can other implementations, but this makes no sense in the context of GLUE, as GLUE is about publishing, I would advise against writing a client software dependent upon on entities that may or may not exist dynamically.
Experiments have the Freedom of choice project to say where they want to write.
That's nothing to do with GLUE per se.
I disagree, GLUE is the foundation upon which many systems such as "Freedom of choice" can depend.
FoC is not a project, it's a rather hacky solution to a specific problem and is also specific to EGEE and to the BDII.
If it is a "hacky solution" why is that? Could you elaborate? I can only guess you think it is because GLUE need to be simplified?
And apart from that, the current implementation works by editing the ACL on the CE, so it's hardly an argument for not having ACLs!
I just do not understand your logic here at all, you need to expand considerably if I am to understand you.
From a purely
LCG/EGEE perspective it's actually the DPM authorisation model we would like to have and dcache and castor should come in line. This is a mater of opinion, I suggest prime mover advantage is important but not the only factor in desiding.
It's not my decision to make, but it was the decision of the recent EGEE authz working group:
https://edms.cern.ch/document/887174/1
(Recommendations document, rec. 12).
I cannot recommend that what you reference should sway GLUE in believing that this is definitive, even if the thanked people and referees where included as authors it does not include many who I should expect within wLCG or glite. It also does not reflect the latest wLCG SRM MOU, where features are discussed with the relevant parties, which directly contradicts your ACL assertions about it being fixed. I would take this document as authoritative for wLCG if it included the all the parties in the wLCG SRM MOU, can you please get them all to agree to this document or withdraw this assertion.
I feel my proposal for VO-Objects and specialisations target at services and VO's appeals more and more.
Frankly it's irrelevant to the current discussion, glue 2 is now basically fixed and we aren't going to make any fundamental changes at this stage.
I first suggested this for GLue 1.1 but I then accepted it was not backwards compatible with Glue 1.0, and have presented it repeatedly as what I consider an important simplification. Since you suggest "glue 2 is now basically fixed" I suggest defending ACL's is inconsistent with your above statement. Regards Owen Synge Paul Millar represents dCache. I represent only my own opinions.
Hi Stephen, Discussion about ACLs aside, I was a bit confused by: On Wednesday 07 May 2008 15:18:57 Burke, S (Stephen) wrote:
[...] and in any case GLUE is designed for dynamic data, at least down to a timescale of a few minutes.
This runs somewhat counter to what I understood for GLUE: that is should be independent of how the information propagates. Since the propagation might be "slow", GLUE should have mostly static (or slowly changing) information. Does GLUE require an information system to respond quickly? If so, on what time-scale? For comparison, here's an estimate of the liveliness of EGEE's information system. I'm hoping Laurence will correct me here, but I believe the picture is roughly: o Underlying system --> GIP plugin (takes ~10s, for all plugins), o GIP-plugin --> GIP (results are cached for 60s), o GIP --> resource BDII (maximum age of data is 60s, by default), o resource BDII makes new data "live" (~1s?), o resource BDII --> site BDII (max. age is 60s?), o site BDII makes new data "live" (~10s?), o site BDII --> top-level BDII (max age of data 60s?). o top-level BDII makes new data "live" (~30s?) So, worse-case delay is the simple sum of these: 291s or the best part of five minutes. Although, I'm guessing this is slightly wrong as (my impression from talking to others is) it can take a bit longer for information to propagate. HTH, Paul.
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: Does GLUE require an information system to respond quickly? If so, on what time-scale?
Well, we use the CE information for scheduling, so it needs to be fast enough to give a reasonable representation of e.g. the number of jobs in a queue. As a rough guide, say you have 1000 job slots and jobs typically run for 10 hours, you might have a transition every 30 seconds or so. However, you don't need accuracy down to the level of a single job, so a latency of a few minutes is OK and typically that's what we have now. On the other hand a latency of an hour would not be good enough, the queue state could change quite dramatically in that time. It's also worth remembering that the batch schedulers themselves have cycle times, typically something like 30 seconds I think, so there is no point in the info system being faster than that. It has often been suggested that we should separate dynamic and static data so we could get frequent updates of the small amount of dynamic information and longer-lived caches for the static stuff. I think Laurence has done some work along those lines for the BDII, but at the moment everything is treated the same way.
So, worse-case delay is the simple sum of these: 291s or the best part of five minutes.
That's probably about right. In the original design for the WMS it queried the GRIS directly before submitting a job to get more recent data than from the II, but we disabled that a long time ago because it was inefficient and didn't make much practical difference - where we have problems they tend to be more fundamental, e.g. poor algorithms for EstimatedTraversalTime or black-hole WNs which fail jobs quickly and hence give a small ERT. Stephen
From: Owen Synge <owen@alice-dsl.de> To: "owen.synge@desy.de" <owen.synge@desy.de> Subject: Re: [glue-wg] Comparison with CIM Date: Sat, 3 May 2008 00:06:39 +0200 X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) On Thu, 1 May 2008 11:52:23 +0100 "Burke, S (Stephen)" <S.Burke@rl.ac.uk> wrote:
it seems that the lack of convergence in authz models has pushed LCG into asking to have two separate kinds of authz (on namespaces and space tokens) and that does need to be considered for GLUE because it would affect the model, e.g. Flavia's proposal to have a new object for namespaces.
Dear Steven, I would support a name space entity in GLUE. Please remember if Paul represents dCache not I. Provided its little more than an entity to provide scoping (VO) and features (Authorisation model, implementation, version number) rather than the content of the name space I would support Flavia's suggestion. Certainly authorisation model would be best expressed in a name space. If the name space content where to be duplicated in GLUE I would strongly oppose it. I believe that a name space maybe independent of a storage element. But that storage elements may reference them which is the case within a wLCG context. This would be useful as for example FERMI have many logically separate name spaces for a single dCache instance, while NorduGrid have many Storage elements with a single namespace. I feel that a name space is a useful discoverable service that wLCG assumes is currently tightly coupled to the storage element, but its equally applicable to a replica catalogue. I would also hope that we would also have one name space for a logical name space and them all associated with a Parent name space, similar to a UNIX mount since we have converged on a hierarchical model. If/when the name space directories support different collections of VO's then I suggest they should be separate instances. eg /castor/cern.ch /castor/cern.ch/cms should be two name spaces to my mind one for all supported VO's and one for CMS in this example. I also see one or more synchronisation services associated to a name space for synchronisation between catalogues and storage elements. Regards Owen Synge
Hi Owen,
[...] leave out Castor and DPM due to the low level of storage deployment they have compared to dCache.
Last time I checked there were some 130 DPM installations, compared to some 60 dCache and 7 CASTOR installations. The amount of disk storage at the dCache T1 and T2 sites will be larger than that of CASTOR (T0, T1) and DPM (T2) combined, but not by a lot, maybe 60 vs. 40%. For tape it is 50-50. I would not call that low at all, certainly not w.r.t. GLUE: there the DPM sites supporting many VOs might well dominate!
On Fri, 2 May 2008 02:33:20 +0200 <Maarten.Litmaath@cern.ch> wrote:
Hi Owen,
[...] leave out Castor and DPM due to the low level of storage deployment they have compared to dCache.
Last time I checked there were some 130 DPM installations, compared to some 60 dCache and 7 CASTOR installations.
The amount of disk storage at the dCache T1 and T2 sites will be larger than that of CASTOR (T0, T1) and DPM (T2) combined, but not by a lot, maybe 60 vs. 40%. For tape it is 50-50.
I would not call that low at all, certainly not w.r.t. GLUE: there the DPM sites supporting many VOs might well dominate!
Hello Maarten, even if Jamie Shears is wrong with his figures on relative storage within wLCG (1/3 of grids within GLue) and I would be surprised since he is the coordinator of wLCG (and he presented this figure in HEPIX last year the 60% of wLCG storage is dCache) The most important point is that we all agree that GLUE is not to drive storage requirements through its representation of the system. (note representation not model) Irrespective of which SRM implementation people prefure the problem does not disappear just by arguing over ACL implementations . I hope you accept my argument that other systems are significant? I would suggest you all consider that wLCG should first agree on a format before we try and put it in GLUE, I hope you agree? We can all pick our own preferred standard, and our favourite implementation, but this in no way effects anything as the outcome (can we write or read) will always resolve to TRUE or FALSE for a given operation, do you agree? Since the outcome resolves to TRUE or FALSE and experiments store where they write data, the experiment is better placed to store the resolved value since this is both already stored and already expressed in a standardised way, for example in FOC? I am sorry but GLUE cannot be everything, I see it as an advertising service, upon which other things can represent information. I hope others also recognise the point of the FOC initiative, and if they do, and still favor ACL's they should explain why they dont see it as part of FOC? Regards Owen Synge
Hi Owen,
The most important point is that we all agree that GLUE is not to drive storage requirements through its representation of the system.
(note representation not model)
Indeed, and the possibility of expressing ACLs in GLUE is not driving storage requirements.
Irrespective of which SRM implementation people prefure the problem does not disappear just by arguing over ACL implementations . I hope you accept my argument that other systems are significant?
I would suggest you all consider that wLCG should first agree on a format before we try and put it in GLUE, I hope you agree?
No. GLUE should allow the _notion_ of ACLs to be expressed where they might reasonably be needed. And we already have ACLs, namely ACBRs. They do not impose particular semantics. Instead they allow for any schema and schema-dependent notions to be expressed. The VO and VOMS schemas are just popular examples of an open-ended enumeration. A grid can decide which schemas it supports.
We can all pick our own preferred standard, and our favourite implementation, but this in no way effects anything as the outcome (can we write or read) will always resolve to TRUE or FALSE for a given operation, do you agree?
Since the outcome resolves to TRUE or FALSE and experiments store where they write data, the experiment is better placed to store the resolved value since this is both already stored and already expressed in a standardised way, for example in FOC?
That is a slippery slope. You could do away with most if not all of the information expressible in GLUE: it could all be remembered in VO-specific services... That happens to be what some of the LHC experiments are doing, but that was because of (past) instabilities in the standard information system. We would not want to give VOs even more reasons for bypassing it...
I am sorry but GLUE cannot be everything, I see it as an advertising service, upon which other things can represent information. I hope others also recognise the point of the FOC initiative, and if they do, and still favor ACL's they should explain why they dont see it as part of FOC?
Advertizing what? "You might store a file here, just try it and remember the outcome for the next time?"
On Fri, 2 May 2008 20:01:32 +0200 <Maarten.Litmaath@cern.ch> wrote: Hello Maarten,
I would suggest you all consider that wLCG should first agree on a format before we try and put it in GLUE, I hope you agree?
No. GLUE should allow the _notion_ of ACLs to be expressed where they might reasonably be needed. And we already have ACLs, namely ACBRs. They do not impose particular semantics.
I would suggest ACBRs are incomplete and not rich enough to be of much use, mainly because they do not impose particular semantics, and map poorly to a ACL, so as to be misleading.
Instead they allow for any schema and schema-dependent notions to be expressed. The VO and VOMS schemas are just popular examples of an open-ended enumeration. A grid can decide which schemas it supports.
I am happy to standardise where things are needed, and support adding Name spaces as a new Glue service for example. I am less happy to express things in GLUE particularly if it puts sites in a position of conflict of interest, I fear that ACL's are coupled with the concept of where experimental VO's want to store data rather than within the concept of Site VO's.
We can all pick our own preferred standard, and our favourite implementation, but this in no way effects anything as the outcome (can we write or read) will always resolve to TRUE or FALSE for a given operation, do you agree?
Since the outcome resolves to TRUE or FALSE and experiments store where they write data, the experiment is better placed to store the resolved value since this is both already stored and already expressed in a standardised way, for example in FOC?
That is a slippery slope. You could do away with most if not all of the information expressible in GLUE: it could all be remembered in VO-specific services...
Certainly this argument could be taken a lot further and I would encourage it, but it definitely could not remove all details from GLUE, which is used to discover available services. In this case, it is an especially pragmatic solution. Other similar arguments are that I would not expect to standardise experimental work flow as they will all work their own way. Furthermore standardising on an incomplete ACL implementation would in my opinion just be misleading and effort. Worse than this they will cause confusion in the comprehension for users. VO's will not find much use in reducing ACL's to a misleading 1 dimensional enumeration unless they are limited to use no more than a 1 dimensional enumeration.
That happens to be what some of the LHC experiments are doing, but that was because of (past) instabilities in the standard information system. We would not want to give VOs even more reasons for bypassing it...
Here I disagree, I know the LHC experiments are blacklisting and white listing sites. I even know sites strive to get back on experimental white lists, as we all want jobs to successfully run at our own sites. Do you agree that white listing is an alternative justification for LHC experiments enhancing GLUE to their own needs?
I am sorry but GLUE cannot be everything, I see it as an advertising service, upon which other things can represent information. I hope others also recognise the point of the FOC initiative, and if they do, and still favor ACL's they should explain why they dont see it as part of FOC?
Advertizing what? "You might store a file here, just try it and remember the outcome for the next time?"
Yes exactly. Please don't confuse GLUE as a mechanism to declare that services exist with the concept of services will be used. White listing of sites is even performed by the VO EGEE. (we call it SFT's) pilot jobs should be embraced by the wLCG community and we should learn the lessons as the Grids evolve to a more workable environments and not just for compute but also storage. As you say LHC experiments already do this and for many good reasons, one of many is that GLUE can never be a complete model only a representation of a site by a site. Site functional tests are an example of this by the VO wLCG. White lists for specific tasks cover all the so far suggested reasons for ACL's within GLUE. ACL's evaluate to TRUE or FALSE for READ and WRITE operations and can be set by VO's. Its the experimental VO's business to even allow them to be read by third parties. Sites that are removed from white lists already strive to be put back on white lists. White and Black listing, Reliability metrics and work flow hints, such as to migrate data from a site after processing is exactly the remit of publish and subscribe systems and they are fit for this purpose but outside the scope of GLUE, as GLUE is provided by sites not by experiments. Experiments would never white list a storage area they had denied them selves access to. Publishing sites service in GLUE, which are refined by white listing of services covers all the use cases presented for ACL's within GLUE and should not be provided by GLUE as they are experiment specific and not site specific. I am yet to see a use case for ACL's within GLUE, not covered by experiments own whitelists, maybe people advocating them are not justifying the case for them in GLUE adequately for me to understand or their is no reason to include them in GLUE. Regards Owen Synge
Hi Owen,
I would suggest you all consider that wLCG should first agree on a format before we try and put it in GLUE, I hope you agree?
No. GLUE should allow the _notion_ of ACLs to be expressed where they might reasonably be needed. And we already have ACLs, namely ACBRs. They do not impose particular semantics.
I would suggest ACBRs are incomplete and not rich enough to be of much use, mainly because they do not impose particular semantics, and map poorly to a ACL, so as to be misleading.
I think we agree after all: I was not suggesting we support anything new beyond allowing for another ACBR schema, which we already do by design. We probably would need significant discussion and/or practical experience with ACLs before we could represent ACLs with their own set of attributes. An example mixing grid authorization notions with POSIX ACL syntax: GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwx GlueAccessControlEntry: /someVO/Role=admin::rwx GlueAccessControlEntry: other::r-x GlueAccessControlEntry: default:user::rwx GlueAccessControlEntry: default:group::rwx GlueAccessControlEntry: default:other::r-x GlueAccessControlEntry: mask::rwx Or with AFS ACL syntax: GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rlidwa GlueAccessControlEntry: /someVO/Role=admin::rlidwa GlueAccessControlEntry: other::rl Or with NTFS ACL syntax: GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwxdpo GlueAccessControlEntry: /someVO/Role=admin::rwxdpo GlueAccessControlEntry: other::rx Or yet some other schema, or a combination of schemas...
[...]
Do you agree that white listing is an alternative justification for LHC experiments enhancing GLUE to their own needs?
Yes, I agree that VO annotations would be cleaner than the FCR hack that is in use today. Something for GLUE > 2.0.
[...]
Please don't confuse GLUE as a mechanism to declare that services exist with the concept of services will be used. White listing of sites is even performed by the VO EGEE. (we call it SFT's)
Yes, but it is not very nice to design the information system as having incomplete information as a principle! The idea is that a client should not have to bother a service too quickly, to find out if its request has a chance of succeeding. If some VO is not advertized as being supported by a particular service, a client representing that VO knows that it need not bother with that service. In the case of ACLs the issue is how fine- grained the information needs to be. Maybe it is sufficient to know that the VO or VOMS FQAN in principle has the desired access, and that further details can be obtained by querying the service directly. Or maybe that service would then find itself being queried all the time, because the VO does not remember the information, because it does not want to create its own information system!
[...]
I am yet to see a use case for ACL's within GLUE, not covered by experiments own whitelists, maybe people advocating them are not justifying the case for them in GLUE adequately for me to understand or their is no reason to include them in GLUE.
Whitelists normally are not sufficiently fine-grained. They typically amount to usable-unusable distinctions, viewed from the VO as a whole. An SE may be declared OK, but then you still may need to find out which path to use for a particular space if you have a particular VOMS FQAN. That information happens to be published already in 1.3, but maybe we will find it is not enough. Anyway, if I had to choose today, I would not invent namespace objects for 2.0, as they would complicate queries and I find the use case presented not sufficiently well-established, but rather a (hopefully) temporary weakness in the current state of affairs in SRM v2.2 land...
Hi Maarten, On Tuesday 06 May 2008 00:11:51 Maarten.Litmaath@cern.ch wrote:
An example mixing grid authorization notions with POSIX ACL syntax:
GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwx GlueAccessControlEntry: /someVO/Role=admin::rwx GlueAccessControlEntry: other::r-x GlueAccessControlEntry: default:user::rwx GlueAccessControlEntry: default:group::rwx GlueAccessControlEntry: default:other::r-x GlueAccessControlEntry: mask::rwx
Or with AFS ACL syntax:
GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rlidwa GlueAccessControlEntry: /someVO/Role=admin::rlidwa GlueAccessControlEntry: other::rl
Or with NTFS ACL syntax:
GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwxdpo GlueAccessControlEntry: /someVO/Role=admin::rwxdpo GlueAccessControlEntry: other::rx
... which illustrates the problem with publishing ACLs nicely. On seeing an entry like: GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwx does a client assume that the ACL is POSIX one (user can do all operations), or a AFS one (user can't do "lida"), or an NFS one (can't do "dpo"), or [...] A client simply can't tell. A grid (e.g., WLCG) might standarise on one but this is irrelevant: GLUE is about cross-grid standardisation, right? Moreover, since a site might publish authz info with any (valid) ACL format, a client must be able to understand *all* potential ACL formats and how the permissions map to the operation the client wants to undertake. For operation X, what permissions are needed for POSIX-like ACLs, and for AFS and for NTFS, and for NFS, and for GPFS, and for [...]; what about operation Y, what permissions are needed for POSIX-like [...]? Even if the information is published and somehow clients can understand all possible information, the published ACLs may still (from practice and legal reasons) be incomplete; even if the client has successfully understood the ACLs there's no guarantee that they will be able to use the service. If we want to publish an authz mapping between users and a service, I feel it should be at a VO level. What are the use-cases for *publishing* finer-grain authorisation? ...and are they reasonable? Cheers, Paul.
Hi Paul,
An example mixing grid authorization notions with POSIX ACL syntax:
GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwx GlueAccessControlEntry: /someVO/Role=admin::rwx GlueAccessControlEntry: other::r-x GlueAccessControlEntry: default:user::rwx GlueAccessControlEntry: default:group::rwx GlueAccessControlEntry: default:other::r-x GlueAccessControlEntry: mask::rwx
Or with AFS ACL syntax:
GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rlidwa GlueAccessControlEntry: /someVO/Role=admin::rlidwa GlueAccessControlEntry: other::rl
Or with NTFS ACL syntax:
GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwxdpo GlueAccessControlEntry: /someVO/Role=admin::rwxdpo GlueAccessControlEntry: other::rx
... which illustrates the problem with publishing ACLs nicely.
On seeing an entry like: GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwx
does a client assume that the ACL is POSIX one (user can do all operations), or a AFS one (user can't do "lida"), or an NFS one (can't do "dpo"), or [...] A client simply can't tell. A grid (e.g., WLCG) might standarise on one but this is irrelevant: GLUE is about cross-grid standardisation, right?
We agree that ACL formats and semantics are not yet well-established at the grid level, so we should not try and quickly get something into GLUE 2.0. Note, however, that the semantics could be explicitly put into each schema, e.g. like this: GlueAccessControlEntry: posix:/DC=ch/DC=cern/.../CN=somebody::rwx GlueAccessControlEntry: afs:/DC=ch/DC=cern/.../CN=somebody::rlidwa GlueAccessControlEntry: ntfs:/DC=ch/DC=cern/.../CN=somebody::rwxdpo
Moreover, since a site might publish authz info with any (valid) ACL format, a client must be able to understand *all* potential ACL formats and how the
Here I do not agree. A client can simply ignore stuff it does not understand. For example, we now publish both "VO:atlas" and "VOMS:/atlas" ACBRs, the latter being ignored by old clients. A service can support multiple interfaces.
permissions map to the operation the client wants to undertake. For operation X, what permissions are needed for POSIX-like ACLs, and for AFS and for NTFS, and for NFS, and for GPFS, and for [...]; what about operation Y, what permissions are needed for POSIX-like [...]?
Even if the information is published and somehow clients can understand all possible information, the published ACLs may still (from practice and legal reasons) be incomplete; even if the client has successfully understood the ACLs there's no guarantee that they will be able to use the service.
True, there can be other restrictions that are not published.
If we want to publish an authz mapping between users and a service, I feel it should be at a VO level. What are the use-cases for *publishing* finer-grain authorisation? ...and are they reasonable?
We already have finer-grain authorization today, viz. per VOMS FQAN, and that is certainly what e.g. ATLAS and LHCb are expecting. Moreover, MyProxy servers even publish the individual DNs that they trust!
Hi Maarten, On Tuesday 06 May 2008 22:56:37 Maarten.Litmaath@cern.ch wrote:
An example mixing grid authorization notions with POSIX ACL syntax: [snip: similarly published ACLs] ... which illustrates the problem with publishing ACLs nicely.
On seeing an entry like: GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwx
does a client assume that the ACL is POSIX one [... or ... or ...]
We agree that ACL formats and semantics are not yet well-established at the grid level, so we should not try and quickly get something into GLUE 2.0.
Agreed, but I would say the problem is a little deeper: with ACLs for certain objects, the ACL semantics may be implementation specific and outside of Glue's (or "the grid's") control. For this reason, it may be impossible for harmonisation of semantics to occur.
Note, however, that the semantics could be explicitly put into each schema, [...]
Yes, absolutely right: one can mark-up the ACL entries. This gets around the "identifying the rules" problem, but creates another one. It would require the client to hold some database of known ACL schemata (AFS vs NTFS vs...), along with a mapping between user operations and corresponding required ACE entries for each of the supported ACL schema.
Moreover, since a site might publish authz info with any (valid) ACL format, a client must be able to understand *all* potential ACL formats and how the
Here I do not agree. A client can simply ignore stuff it does not understand.
Perhaps, as a fall-back policy, a client can simply "try its luck" and see whether the operation succeeds.
For example, we now publish both "VO:atlas" and "VOMS:/atlas" ACBRs, the latter being ignored by old clients.
Whilst you're quite correct in saying that publishing both "VO:atlas" and "VOMS:/atlas" allows for backward compatibility, I suspect that this is a special case. In general, one cannot precisely map an ACE from one ACL schema to another; for example, what POSIX ACE should be published for the following AFS ACE? GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::lkd
A service can support multiple interfaces.
Yes, but only if the service happens to support both interfaces, and this is only helpful if all clients understand at least one of the interfaces. The equivalent would be if a filesystem happens to support multiple ACL schemata (e.g., both AFS and NTFS ACLs) so both could be published. This may be technically feasible (anything's possible!), but I doubt any filesystem supports more than one ACL schema. [...]
If we want to publish an authz mapping between users and a service, I feel it should be at a VO level. What are the use-cases for *publishing* finer-grain authorisation? ...and are they reasonable?
We already have finer-grain authorization today, viz. per VOMS FQAN, and that is certainly what e.g. ATLAS and LHCb are expecting.
Ah! But these aren't really ACLs as don't specify the permitted operations. They're more like the mapping between user-community and some object within the Glue schema. This is more what I meant by at a "VO level": (sorry, I should have used the term user-community or "UserDomain").
Moreover, MyProxy servers even publish the individual DNs that they trust!
Ah, sorry, I don't know enough about MyProxy, but isn't this a trust issue rather than one of authorisation? Cheers, Paul.
Hi Paul,
[...]
Yes, absolutely right: one can mark-up the ACL entries. This gets around the "identifying the rules" problem, but creates another one. It would require the client to hold some database of known ACL schemata (AFS vs NTFS vs...), along with a mapping between user operations and corresponding required ACE entries for each of the supported ACL schema.
Not each, just the ones it cares about. Analogy: a product wrapper may have the same text in multiple languages - just pick the one(s) you understand. The texts need not even be equivalent, e.g. because of different laws or cultures in different countries.
Moreover, since a site might publish authz info with any (valid) ACL format, a client must be able to understand *all* potential ACL formats and how the
Here I do not agree. A client can simply ignore stuff it does not understand.
Perhaps, as a fall-back policy, a client can simply "try its luck" and see whether the operation succeeds.
Right. If the understandable information did not rule out success, the client might give it a try.
For example, we now publish both "VO:atlas" and "VOMS:/atlas" ACBRs, the latter being ignored by old clients.
Whilst you're quite correct in saying that publishing both "VO:atlas" and "VOMS:/atlas" allows for backward compatibility, I suspect that this is a special case.
In general, one cannot precisely map an ACE from one ACL schema to another; for example, what POSIX ACE should be published for the following AFS ACE? GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::lkd
There is no need to map it to another ACL schema. The service is saying: if you happen to understand AFS ACLs, I can tell you that the given DN has "lkd" permissions. (There should be a schema prefix like "afs:").
A service can support multiple interfaces.
Yes, but only if the service happens to support both interfaces, and this is only helpful if all clients understand at least one of the interfaces.
The equivalent would be if a filesystem happens to support multiple ACL schemata (e.g., both AFS and NTFS ACLs) so both could be published. This may be technically feasible (anything's possible!), but I doubt any filesystem supports more than one ACL schema.
I should have been clearer. In my GLUE example the "posix"/"afs"/"ntfs"/... schemas need not mean that the server actually runs such a file system or equivalent: I used the schema to define a policy _language_.
[...]
If we want to publish an authz mapping between users and a service, I feel it should be at a VO level. What are the use-cases for *publishing* finer-grain authorisation? ...and are they reasonable?
We already have finer-grain authorization today, viz. per VOMS FQAN, and that is certainly what e.g. ATLAS and LHCb are expecting.
Ah! But these aren't really ACLs as don't specify the permitted operations.
The operations are implicit: posix:rwx afs:rlidw(a) ntfs:rwxd(p) More interesting ACLs might look like this: srmv22:/someVO/admin:rw srmv22:/someVO:w They would be for a space that can be used as a write buffer by the whole VO, but as a read buffer only by privileged FQANs within the VO.
They're more like the mapping between user-community and some object within the Glue schema. This is more what I meant by at a "VO level": (sorry, I should have used the term user-community or "UserDomain").
Moreover, MyProxy servers even publish the individual DNs that they trust!
Ah, sorry, I don't know enough about MyProxy, but isn't this a trust issue rather than one of authorisation?
It is another illustration that the VO level is not fine-grained enough for GLUE.
Hi Paul, I'm adding some piece of information to the already clear summary provided by Laurence. 1. CIM is a model that we are aware of; I've personally presented a couple of times our work to their community: DMTF Symposium 2007 http://www.mandevcon.com/2007/schedule.html MDC 2007 (http://www.mandevcon.com/2007/schedule.html) presentation here: http://omii-europe.forge.cnaf.infn.it/jra2/presentation?s=mdc it is clear that we model for different goals; there is actually a document edited mainly by Ellen Stokes to which I contributed for the GLUE part that you may want to read: http://forge.ogf.org/sf/sfmain/do/downloadAttachment/projects.ggf-editor/tra... 2. DMTF and OGF relationship there is an official agreement between OGF and DMTF (called work register) for collaborating on well-defined topics; one of this is to render GLUE as CIM extension; the activity has not yet really started; firstly because we need a mature proposal (and we almost have), secondly, because there are other issues to be sorted out such as availability of people from both sides to do the real work 3. WBEM GLUE is not rendered following the CIM meta-model, nevertheless we can exploit WBEM technologies to build a framework for GLUE 2 providers. In the context of OMII-Europe, we actually spent the last months on building such a framework; our software is called GLUEMan and relies on OpenPegasus We plan to release the beta version with new features in the coming days: http://glueman.sourceforge.net/ I plan to present this work also at the next OGF You can find more details on the architecture of GLUEMan in the our milestone document M:JRA2.2: http://omii-europe.forge.cnaf.infn.it/jra2/documentation Cheers, Sergio Paul Millar wrote:
Hi all,
I don't know if anyone has been looking at this, but there's an emerging standard (through DMTF) in modelling "things" (computer-hardware and -software, network equipment, etc): CIM. There seems to be some cross-over here through OGF, so forgive me if this is already "well known".
Anyway, for those who haven't heard of them, their schema makes for interesting reading. The current version (2.18) is available from: http://www.dmtf.org/standards/cim/cim_schema_v218
"Device" (from which a StorageDevice may be published)
http://www.dmtf.org/standards/cim/cim_schema_v28/CIM_Device28-Final.pdf
How to publish ACLs:
http://www.dmtf.org/standards/cim/cim_schema_v218/CIM_Policy.pdf
Enjoy!
Paul. _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- 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
Hi Sergio, Thanks for the information: all very interesting. Could all this be put into a wiki page? It seems a shame that related activity and projects, like GLUEMan, aren't mentioned by on the GLUE wiki. Cheers, Paul. On Tuesday 29 April 2008 18:30:20 Sergio Andreozzi wrote:
Hi Paul,
I'm adding some piece of information to the already clear summary provided by Laurence.
1. CIM is a model that we are aware of; I've personally presented a couple of times our work to their community:
DMTF Symposium 2007 http://www.mandevcon.com/2007/schedule.html
MDC 2007 (http://www.mandevcon.com/2007/schedule.html) presentation here: http://omii-europe.forge.cnaf.infn.it/jra2/presentation?s=mdc
it is clear that we model for different goals; there is actually a document edited mainly by Ellen Stokes to which I contributed for the GLUE part that you may want to read:
http://forge.ogf.org/sf/sfmain/do/downloadAttachment/projects.ggf-editor/tr acker.submit_ggf_draft/artf6153?id=atch4608
2. DMTF and OGF relationship
there is an official agreement between OGF and DMTF (called work register) for collaborating on well-defined topics; one of this is to render GLUE as CIM extension; the activity has not yet really started; firstly because we need a mature proposal (and we almost have), secondly, because there are other issues to be sorted out such as availability of people from both sides to do the real work
3. WBEM
GLUE is not rendered following the CIM meta-model, nevertheless we can exploit WBEM technologies to build a framework for GLUE 2 providers.
In the context of OMII-Europe, we actually spent the last months on building such a framework; our software is called GLUEMan and relies on OpenPegasus
We plan to release the beta version with new features in the coming days: http://glueman.sourceforge.net/
I plan to present this work also at the next OGF
You can find more details on the architecture of GLUEMan in the our milestone document M:JRA2.2: http://omii-europe.forge.cnaf.infn.it/jra2/documentation
Cheers, Sergio
Paul Millar wrote:
Hi all,
I don't know if anyone has been looking at this, but there's an emerging standard (through DMTF) in modelling "things" (computer-hardware and -software, network equipment, etc): CIM. There seems to be some cross-over here through OGF, so forgive me if this is already "well known".
Anyway, for those who haven't heard of them, their schema makes for interesting reading. The current version (2.18) is available from: http://www.dmtf.org/standards/cim/cim_schema_v218
"Device" (from which a StorageDevice may be published)
http://www.dmtf.org/standards/cim/cim_schema_v28/CIM_Device28-Final.pdf
How to publish ACLs:
http://www.dmtf.org/standards/cim/cim_schema_v218/CIM_Policy.pdf
Enjoy!
Paul. _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
participants (8)
-
Burke, S (Stephen) -
Gordon, JC (John) -
Laurence Field -
Maarten.Litmaath＠cern.ch -
Owen Synge -
owen.synge＠desy.de
-
Paul Millar -
Sergio Andreozzi