Dear all, The best way to destroy Glue, is to use poorly defined objects, and untested entities relations, that are proprietary to a single or small and legacy subset of Grids, particularly with untested ideas. This will invalidate the purpose of taking your Grid specific views to the OGF. Can I please request that members of Glue trail their ideas on their own grids. I fear some members are unwilling to separate the context of their grids from the greater grid community. Examples include, binding a minority standard (SRM 2.2 and only its static spaces) into the Glue schema when numerous other examples exist such as GPFS, and NFS v4. Binding a minority authentication mechanism (VOMS) when SAML and numerous other standards are more commonly used. This may be forgivable if the people involved had tested these representations, I know from the threads on the mailing list that these ideas are new. I wish to complement Laurence on trying to stop the destruction of his work on the Glue standard, but this continued tight coupling to minority Grid services (VOMS/SRM 2.2) will lead to a legacy standard that all future grids should abandon in favour of something workable for them, if you have not even tested your ideas you should not be proposing them as a standard, that's your Grid's research work and not for OGF, which is for consolidating the Engineering objectives of interoperability. Please consider rolling out these suggestions on your own information systems AND get them WORKING before adding them to a inter grid standard. Regards Owen Synge I do not represent Dcache or DESY in my above objections, just my education as an engineer. Engineering is often about rejecting use cases so more important objectives can be achieved.
Dear Owen, I understand your concerns, nevertheless I believe that it is time for the GLUE spec to be exposed to a larger audience for review (that means going public comments). We have been digesting concepts for more than one year and it is time now to close the pending issues, clean-up the spec, align the rendering to different concrete data models and send everything to the larger audience for review. This will allow us to concentrate for a 60 days period on a more extensive implementation activity. Also, other groups can use a clean snapshot to evaluate our work and express a different viewpoint. At the end of this period, all the feedback will be applied to the specification and, depending on the amount of changes, the spec can be asked to go again on public comment or, in the best case, to the proposed recommendation. Proposed recommendation are a stable basis for further experience and review towards the state of full OGF recommendation. Given our working conditions, I consider going public comment soon as a necessary step of the engineering process for GLUE. The community will promote it to a proposed recommendation when the spec will be considered mature. I took note of the technical comments that I could extract from your e-mail and I wish to see more of them any time in the future. Regards, Sergio Owen Synge wrote:
Dear all,
The best way to destroy Glue, is to use poorly defined objects, and untested entities relations, that are proprietary to a single or small and legacy subset of Grids, particularly with untested ideas. This will invalidate the purpose of taking your Grid specific views to the OGF.
Can I please request that members of Glue trail their ideas on their own grids. I fear some members are unwilling to separate the context of their grids from the greater grid community.
Examples include, binding a minority standard (SRM 2.2 and only its static spaces) into the Glue schema when numerous other examples exist such as GPFS, and NFS v4. Binding a minority authentication mechanism (VOMS) when SAML and numerous other standards are more commonly used. This may be forgivable if the people involved had tested these representations, I know from the threads on the mailing list that these ideas are new.
I wish to complement Laurence on trying to stop the destruction of his work on the Glue standard, but this continued tight coupling to minority Grid services (VOMS/SRM 2.2) will lead to a legacy standard that all future grids should abandon in favour of something workable for them, if you have not even tested your ideas you should not be proposing them as a standard, that's your Grid's research work and not for OGF, which is for consolidating the Engineering objectives of interoperability. Please consider rolling out these suggestions on your own information systems AND get them WORKING before adding them to a inter grid standard.
Regards
Owen Synge
I do not represent Dcache or DESY in my above objections, just my education as an engineer. Engineering is often about rejecting use cases so more important objectives can be achieved. _______________________________________________ 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 Owen, Thanks for the complement :) I would first like to point out that glue schema is definitely NOT my work. Glue is a community driven activity in which I am participating as a member of that community. The excellent progress that we have made with glue has been due to the participation of everyone involved and in the way that we are collaborating together as a group. I understand your point of view and share it to a point, however, this is only one side of the argument. Like most standards for it to be successful, it has to be adopted by the community. One of the values of Glue is that it is being defined by the communities that need it so there is case for it to be adopted. However, there is a fine line in defining something general that meets everyones requirements and yet meets all existing use cases. Whatever your opinion is on various aspect of the VOMS/SRM use case and its lifetime, it is widely used and something that we can't ignore. The one things that we have learnt from all the schema discussions in the past is that whatever we define will have imperfections and will need to be revised in an newer version. It is important that we focus on the things that we believe we understand and which have been proven in deployment scenarios. For the things that we don't understand well and have little experience with we should spend less effort and wait until we understand them better. What we define for Glue 2.0 is not the end but just the beginning of a continual process of refinement a based on the feedback we receive from the real deployment. Laurence Owen Synge wrote:
Dear all,
The best way to destroy Glue, is to use poorly defined objects, and untested entities relations, that are proprietary to a single or small and legacy subset of Grids, particularly with untested ideas. This will invalidate the purpose of taking your Grid specific views to the OGF.
Can I please request that members of Glue trail their ideas on their own grids. I fear some members are unwilling to separate the context of their grids from the greater grid community.
Examples include, binding a minority standard (SRM 2.2 and only its static spaces) into the Glue schema when numerous other examples exist such as GPFS, and NFS v4. Binding a minority authentication mechanism (VOMS) when SAML and numerous other standards are more commonly used. This may be forgivable if the people involved had tested these representations, I know from the threads on the mailing list that these ideas are new.
I wish to complement Laurence on trying to stop the destruction of his work on the Glue standard, but this continued tight coupling to minority Grid services (VOMS/SRM 2.2) will lead to a legacy standard that all future grids should abandon in favour of something workable for them, if you have not even tested your ideas you should not be proposing them as a standard, that's your Grid's research work and not for OGF, which is for consolidating the Engineering objectives of interoperability. Please consider rolling out these suggestions on your own information systems AND get them WORKING before adding them to a inter grid standard.
Regards
Owen Synge
I do not represent Dcache or DESY in my above objections, just my education as an engineer. Engineering is often about rejecting use cases so more important objectives can be achieved. _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Dear all, Thankyou Laurence and Sergio, I am pleased that you both share my concerns, although less alarmist than I it has been clear from your steadying hands that you are also concerned about the creeping scope from discovery to modeling and monitoring within Glue. How do I think it could all be resolved so that the experiments and the people who want Glue to be a standard for more than HEP can coexist happily? I feel that Glue and HEP should acknowledge that we are working on a schema, and the great thing about schema's is they can be extended, or in OO speak specialised. I acknowledge that we have some use cases that require publishing and subscribing, and that HEP grids have little choice but to use established Grid infrastructure for there short term production needs. This is not Glue, just the infrastructure for distributing data. So I propose that HEP dominated grids such as wLCG, OSG and NorduGrid should have a separate standardisation process for there extensions to the markup of the there Glue as a separate paper and standard specification. What I see currently particularly in storage is a specialisation of the Tier 1 and Tier 0 markup for wLCG et al Grids. In the context of these grids schema I would find it much more acceptable to add monitoring and Authorization information and even tightly couple to existing Grid infrastructures. Even if I feel that a relational database is a more natural fitting for some fields. In and ideal world I would also allow VO's to be able to publish VO specific data within the publish subscribe infrastructure that GLue also uses. As I know form previous and continuing standardisation efforts its hard work to get what you need in a standard, allowing a free hand to add and remove markup of sites for experiments may be hugely beneficial, particularly as it would remove an imposition to a liberty. What I object to is the hard work of building an abstract description of a site being specialised to the point where it is no longer universal. I see great danger that Glue will only work in its current form in Tier 0 and Tier 1 sites on HEP community grids, I am even concerned that it will be too heavy weight for tier 2/3 sites. I see Glue as a higher purpose, sharing our experience of building a grid with communities that want to build new potentially better grids or cloud computing infrastructures. We may be holding back its adoption with other grids, and the infrastructure that experiments could effectively use with their own markup. The solution maybe to partition the schema effort into multiple views. Universal, HEP Grid Community (wLCG, OSG and NorduGrid), and VO based schema. Since wLCG and VO's want additional markup on top of Glue they are the ones who should mark up the sites, and quite rightly they should be able to demand from their middle ware additional requirements that would not be universal for all grids. For me Glue is something we should be proud of, as Grid pioneers in wLCG, OSG, NorduGrid and the assorted experimental communities we can give the world of grid computing a basis upon which to share or experience of what is common and clearly separate what is not meant to be universal. This would make me happier Regards Owen Synge
Since my last emails could be misinterpreted without understanding my paradigm, it does help my reputation for trying to help no good without a simple explanation of my view as a perfect solution. At the end I explain how to get their in stages with no new development commissioned. For now lets get to the use case Glue is worrying me its forgetting, its meta data services. VO service objects are not published, hence their use cases go unnoticed, I believe this is because people are unaware the delivery platform for Glue could be used by more schemers. I also believe this has led people to focus on modeling the grid with in Glue rather than describing it, with the intention of further more detailed markup. VO service listing structures could be used by many VO's, obvious examples include service instances that a VO wants to use. More complex examples include Storage Services which should only be used for short term storage, these sort of configuration parameters are really useful to publish, not just for the VO that publishes them but for other VO's potentially as well. Another example is wLCG derived data that should be republished for the benefit of VO's running on wLCG coordinated infrastructure is service relative up time which should be republished from Glue monitoring data. Since I see "dGrid", "Atlas" and "dGrid Atlas" as three VO's I see a strong use case for some VO's to republish or reuse other VO's markup, particularly when for example dGrid may stipulates a quota to non dGrid members and Atlas wants to maximise resource utilisation. Since a BDII infrastructure exists and is extensible to many schema and is already tested, VO's can already publish from static files, or even scripts that perform queries and provide additional markup upon Glue (In which case you have a RDBMS view equivalent), VO boxes can easily publish such VO lists with previous and current versions of Glue, just like services currently do, provided they talk to the software developer and get his consent (Laurence Field) for support and since its just for a VO the parties involved and the standardisation within a VO would help. I personally would like to see Glue decomposed into multiple VO-service objects referenced by schema containing the necessary information for that VO's settings or services description. This would simplify and reduce confusion over what we are all trying to achieve useful service descriptions to all user groups without over burdening standardisation efforts and large scale coordination. This is not essential, but probably desirable for Glue 3.0 For safeties sake I would only reference service identifiers (endpoints) from Glue in a derived schema. Unfortunately I think the VO communities do not realise they could have a lot more useful information if they chose to add their own markup. I think particularly of pilot jobs and steering data transfer between site requests. VO's could build on current infrastructure and see real benefit easily in the publish subscribe infrastructure with minimal effort. Experimental VO's that are decomposed by nation publishing their VO's national VO schema on a VO box, but containing what ever meta data they can to aid resource utilisation, and data management policies for the international VO. This sort of referencing schema is an important use case that I am worried is being buried as Glue addresses services in Unique ways for computing and storage for example. Thus making the derived schema harder than it should be. I assume this is because experimental VO's are unaware of this useful service and how they could use it so are not pressing for the schema to be simpler to work with. I would like Glue to be multiple schema referencing a base schema for service discovery and further mark up only. Thank you for your Patience. Regards Owen Synge Examples of Derived Schema wLCG Monitoring should publish Tier Status, Service Reliability Metrics by Service, and maybe parametrised ranking. HEP experiments should publish the services they want to use with abstract markup such as usage policies and important information derived from the output of pilot jobs, and data retention reliability by service. SRM schema implementation with extended derived schema for Castor, Storm, Dcache and DPM reflecting their unique features and sharing their common features.
Hi Owen I am not sure what you a referring to as VO service objects, please could you explain what you mean by this in more detail. The Glue Schema just defines an abstract vocabulary for describing grid entities. Further markup of the Glue schema during deployment is envisaged and expected. There are various placeholders in existing entries for additional attributes and vendor specific extensions can always be defined. As most of the attributes are optional in Glue, it is not expected that everything will be published, only what is really needed to meet the specific use cases. To ensure interoperation between infrastructures, an interoperability profile needs to be defined which expresses what attributes are mandatory for the cross infrastructure use cases. I completely understand the need for VO based information and the ability to annotate the information. This is a real use case which is already in use for wLCG as you pointed out. However,this has more to do with the information system implementation rather than the schema. Essentially there are two different views of the grid, an infrastructure centric view and a VO centric view. The current version of the schema and information system does in take an infrastructure centric view. The Glue schema is a response to meet the existing demand for such a solution based on the current way of thinking. As grid infrastructures evolve and grid initiatives like EGI have more influence, we might see a paradigm shift which will require a change in Glue. However, before we started defining Glue 2.0, there were many discussions, including alignment with the OGF reference model, all of which have an infrastructure centric view. The problem highlighted is that VOs have there own vocabulary, naming and semantics that is important to them eg the wLCG Tier structures. However, this is specific to the VO and is something that does not need agreement. The VO is free to define there own vocabulary. The real problem is a technical one on how this information is used within an information system. For EGEE we have have evolved various mechanisms to do this, such as the FCR mechanism. I am really happy that you bring up the idea of Glue 3.0! As I said in my previous mail Glue 2.0 is not the end but just the being. As we are currently finalizing the specification, this is the wrong time to revisit the discussions on the fundamental model. Over time and through the influence of EGI etc, we may see a shift in the fundamental model to which this group must respond. Laurence
Hi, Laurence Field wrote:
To ensure interoperation between infrastructures, an interoperability profile needs to be defined which expresses what attributes are mandatory for the cross infrastructure use cases.
As we are _rudimentary and for a prototype_ trying to do exactly that, to map a basic set of attributes from the real technical information schemata used in MDS4, Unicore, BDII into GLUE 2.0, I wondered if somebody is already doing work on interoperability profiles ? -- Dipl-Inf. Timo Baur Leibniz Rechenzentrum Kommunikationsnetze/Netzplanung/D-MON Boltzmannstr. 1 D-85748 Garching Telefon +49 89 35831-8729 Fax +49 89 35831-5729 timo.baur@lrz-muenchen.de
Hi Timo, I don't exactly understand what you mean. However, there was quite a bit of work done related to this in the gin-info group. Two approaches were presented, one was to try and agree on a minmal set off attributes and the other was to try an translate one information schema into another. The conclusion from this work as that we need to have a common vocabably and agree on the fundamental entities that we are dealing with. You can't map something that doesn't exist in one model into the other model and if we have different semantics for something with the same name it can get very confusing if you try and have a conversation. The other problem highlighted was that what is important for one use case is irrelevant for another. As infrastructures only need to interoperate to meet the demand of their users, we have to look at their use cases to understand what is important. This work is currently being investigate in the GIN group. One example is the WN profile which gives recommendation for the configuration of environment variables. I am sure that GIN-CG will define a profile for Glue once it is deployed across the infrastructures. Laurence
As we are _rudimentary and for a prototype_ trying to do exactly that, to map a basic set of attributes from the real technical information schemata used in MDS4, Unicore, BDII into GLUE 2.0, I wondered if somebody is already doing work on interoperability profiles ?
Hi Laurence, That was exactly what I wanted to know. We also try to define a minimal set of attributes and I am going to follow the discussion regarding that in GIN. Thanks, Timo Laurence Field wrote:
Hi Timo,
I don't exactly understand what you mean.
However, there was quite a bit of work done related to this in the gin-info group. Two approaches were presented, one was to try and agree on a minmal set off attributes and the other was to try an translate one information schema into another.
The conclusion from this work as that we need to have a common vocabably and agree on the fundamental entities that we are dealing with. You can't map something that doesn't exist in one model into the other model and if we have different semantics for something with the same name it can get very confusing if you try and have a conversation.
The other problem highlighted was that what is important for one use case is irrelevant for another. As infrastructures only need to interoperate to meet the demand of their users, we have to look at their use cases to understand what is important. This work is currently being investigate in the GIN group. One example is the WN profile which gives recommendation for the configuration of environment variables.
I am sure that GIN-CG will define a profile for Glue once it is deployed across the infrastructures.
Laurence
As we are _rudimentary and for a prototype_ trying to do exactly that, to map a basic set of attributes from the real technical information schemata used in MDS4, Unicore, BDII into GLUE 2.0, I wondered if somebody is already doing work on interoperability profiles ?
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- 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@lrz-muenchen.de
On Thu, 24 Apr 2008 12:17:17 +0200 Laurence Field <Laurence.Field@cern.ch> wrote:
Hi Owen
I am not sure what you a referring to as VO service objects, please could you explain what you mean by this in more detail.
Hello Laurence and All Glue people. All definitions are an attempt within Glue's perspective. Definition ~~~~~~~~~~ A VO Service object is the cross product of the concepts VO and Service and I suggest the fundamental Object that all things in Cloud computing or a Grid are Identified as. This implies a common understanding of the concepts of VO and Service. Principle Definitions ~~~~~~~~~~~~~~~~~~~~~ A VO is more than this it is an abstract collections of users bound to an administrative domain that acquires a legal standing. For the purposes of Glue Specification management I believe it should be a grouping of user requirements. Most members of most grids are members of multiple VO's for example by virtue of my Job, I can be a member of dteam, wlcg, ops, dgrid, sa3, "Eu funded", "Germany Funded" and academic. A service is an abstract catch all for any software that can be operated via a network interface and wishes to advertise its self to a collection of VO's. Clarification ~~~~~~~~~~~~~ A VO Service object is the cross product of the concepts VO and Service, it sole purpose is as a service that is advertised to a VO as potentially useful and exploitable. To try and narrow down a VO service object in more solid form, it would probably have the following attributes. Unique Identifier Site Unique Identifier URI (Uniform Resource Identifier) VO (That it is advertising to) Type (Unique Identifier to the service Type) Implementation (Unique Identifier to Implementation of "Type") Version (Unique Identifier to Version of "Implementation") And maybe a few more mandatory attributes that don't spring to mind, but looking at Glue Service Objects will help. I expect a few optional arguments as well.
The Glue Schema just defines an abstract vocabulary for describing grid entities. Further markup of the Glue schema during deployment is envisaged and expected. There are various placeholders in existing entries for additional attributes and vendor specific extensions can always be defined. As most of the attributes are optional in Glue, it is not expected that everything will be published, only what is really needed to meet the specific use cases. To ensure interoperation between infrastructures, an interoperability profile needs to be defined which expresses what attributes are mandatory for the cross infrastructure use cases.
Im pleased but feel that having much more than VO Service Objects, as a base class and in effect inheriting from them. As a minimum level of clarity is imperative.
I completely understand the need for VO based information and the ability to annotate the information. This is a real use case which is already in use for wLCG as you pointed out.
I know, but I feel that many people, do not realise that VO's can publish. This has led to Glue becoming more complex than absolutely necessary. VO's such as discovery, monitoring and modeling are freely mixing in a single schema where they could more profitably be decomposed but that is future work for Glue 3.0.
However,this has more to do with the information system implementation rather than the schema. Essentially there are two different views of the grid, an infrastructure centric view and a VO centric view. The current version of the schema and information system does in take an infrastructure centric view.
I should like a decomposition of Requirements by VO, each VO having a separate schema. I believe this would lead to the following VO's Discovery (What is a service? computers? storage?) Site (What is in a Site? What Grids does it advertise to support?) Monitoring (reliability,resources) Grid (Grid management, wLCG, NorduGrid, OSG, dGrid) And therefore Schema. I may have missed a Schema out.
The Glue schema is a response to meet the existing demand for such a solution based on the current way of thinking. As grid infrastructures evolve and grid initiatives like EGI have more influence, we might see a paradigm shift which will require a change in Glue. However, before we started defining Glue 2.0, there were many discussions, including alignment with the OGF reference model, all of which have an infrastructure centric view.
Good point, but I see the need to define a index of services to facilitate derived schema, and consider resolving Glue into a series of Derived Schema from VO Service objects. Our infrastructure centric view is just one of the views we are taking in Glue. Therefore I feel Glue better expressed for future uses as three standards at least. With the VO Service Object as the class common to all schema. Glue at this moment is not just infrastructure centric, but is also monitoring and modeling.
The problem highlighted is that VOs have there own vocabulary, naming and semantics that is important to them eg the wLCG Tier structures.
Yes I agree with you Laurence, and suggest that VO's such as wLCG and Nordu Grid should put their Monitoring Requirements in a separate schema and define how service discovery should be unified by, sharing a common VO-Object with the Schema for Service Discovery, but potentially not bound between schema. I would see Monitoring as an area for a much richer schema than is provided by Glue currently. This is for good engineering reasons and to make things interoperable. Hopefully in time Monitoring service Summary output could be standardised to include availability metrics for a variety of service types and implementations.
However, this is specific to the VO and is something that does not need agreement. The VO is free to define there own vocabulary. The real problem is a technical one on how this information is used within an information system. For EGEE we have have evolved various mechanisms to do this, such as the FCR mechanism.
I was unaware of the FCR mechanism. For people who have not looked up what FCR mechanism is its a way so VO's can publish information. Unfortunately Grid wide Monitoring within Glue is potentially changeable, this is why I want VO-Service Objects, and a clear statement that all services are expressed through VO-Service Objects. I feel that transforming Glue to a set of schema that share a common VO-Service Object will massively simplify the FCR mechanism for users and reduce potential tight coupling, and increase interoperability. The danger of not embracing VO-Service objects is that we become unable to send users of Glue a clear way to describe resources consistently and briefly in their own schema as inherited objects as not all services are represented in a consistent way. I fear the consequence of inconsistency of representation of physical entities with in Glue 1.0 and potentially Glue 2.0 will lead to dependent representations suffering greatly when accounting objects are redefined for example. This use case occurred between Glue 1.2 and Glue 1.3.
I am really happy that you bring up the idea of Glue 3.0! As I said in my previous mail Glue 2.0 is not the end but just the being. As we are currently finalizing the specification, this is the wrong time to revisit the discussions on the fundamental model. Over time and through the influence of EGI etc, we may see a shift in the fundamental model to which this group must respond.
I also share Laurence's fears about such a fundamental change as an entity relationship change, but to me the worry is that without re factoring to make the expression of an instance of a Storage element identical to that of the CE (which is I already a VO Service Object derivative) we will make work for users of the FCR and other Schema publishing methods that are used on Grids. If people are aware that the VO Service Object is the identifier of all services it, may well allow smoother progression to multiple Grid providing services. Like Laurence and Sergio, but maybe for different reasons I want to focus on keeping Glue simple, for me this is best expressed as a series of sub schema all referencing a single VO Service Object Entity. I hope Glue 3.0 can be at least 3 schema sharing the common concept of a VO-Service Object and specifying instances of services in terms of VO-Service Objects, for the benefit of interoperability and FCR users. I agree this is too lofty a goal for Glue 2.0. I feel that changing the schema's entity relations in that area has been done so recently its a shame the idea of presenting services in a consistent way has not been received clearly enough from me. Since Glue is such a large effort, and has so many potential Grids as a target audience I feel Glue 2.0 could be improved immensely by simplification by this entity change and facilitate smother progression to Glue 3.0 with FCR users and similar communities. Regards Owen
Hi Owen, The main aim of the Glue Working Group, which is defined in the Working Groups charter, is to consolidate the existing schema already in use into a commonly agreed schema which meets the existing use cases. The plan is following an aggressive time scale to which we are hopefully reaching the end. The schema reflects the current architecture both in topology and tooling already in use across the production infrastructures. It is not the aim of the group to define the architecture for grid computing but just encapsulate it into an information model. However, I am very interested in your ideas and would like to discuss them further but it might be easier on the phone. Speak to you soon. Laurence owen.synge@desy.de wrote:
On Thu, 24 Apr 2008 12:17:17 +0200 Laurence Field <Laurence.Field@cern.ch> wrote:
Hi Owen
I am not sure what you a referring to as VO service objects, please could you explain what you mean by this in more detail.
Hello Laurence and All Glue people.
All definitions are an attempt within Glue's perspective.
Definition ~~~~~~~~~~
A VO Service object is the cross product of the concepts VO and Service and I suggest the fundamental Object that all things in Cloud computing or a Grid are Identified as.
This implies a common understanding of the concepts of VO and Service.
Principle Definitions ~~~~~~~~~~~~~~~~~~~~~
A VO is more than this it is an abstract collections of users bound to an administrative domain that acquires a legal standing. For the purposes of Glue Specification management I believe it should be a grouping of user requirements.
Most members of most grids are members of multiple VO's for example by virtue of my Job, I can be a member of dteam, wlcg, ops, dgrid, sa3, "Eu funded", "Germany Funded" and academic.
A service is an abstract catch all for any software that can be operated via a network interface and wishes to advertise its self to a collection of VO's.
Clarification ~~~~~~~~~~~~~
A VO Service object is the cross product of the concepts VO and Service, it sole purpose is as a service that is advertised to a VO as potentially useful and exploitable.
To try and narrow down a VO service object in more solid form, it would probably have the following attributes.
Unique Identifier Site Unique Identifier URI (Uniform Resource Identifier) VO (That it is advertising to) Type (Unique Identifier to the service Type) Implementation (Unique Identifier to Implementation of "Type") Version (Unique Identifier to Version of "Implementation")
And maybe a few more mandatory attributes that don't spring to mind, but looking at Glue Service Objects will help. I expect a few optional arguments as well.
The Glue Schema just defines an abstract vocabulary for describing grid entities. Further markup of the Glue schema during deployment is envisaged and expected. There are various placeholders in existing entries for additional attributes and vendor specific extensions can always be defined. As most of the attributes are optional in Glue, it is not expected that everything will be published, only what is really needed to meet the specific use cases. To ensure interoperation between infrastructures, an interoperability profile needs to be defined which expresses what attributes are mandatory for the cross infrastructure use cases.
Im pleased but feel that having much more than VO Service Objects, as a base class and in effect inheriting from them. As a minimum level of clarity is imperative.
I completely understand the need for VO based information and the ability to annotate the information. This is a real use case which is already in use for wLCG as you pointed out.
I know, but I feel that many people, do not realise that VO's can publish. This has led to Glue becoming more complex than absolutely necessary.
VO's such as discovery, monitoring and modeling are freely mixing in a single schema where they could more profitably be decomposed but that is future work for Glue 3.0.
However,this has more to do with the information system implementation rather than the schema. Essentially there are two different views of the grid, an infrastructure centric view and a VO centric view. The current version of the schema and information system does in take an infrastructure centric view.
I should like a decomposition of Requirements by VO, each VO having a separate schema. I believe this would lead to the following VO's
Discovery (What is a service? computers? storage?) Site (What is in a Site? What Grids does it advertise to support?) Monitoring (reliability,resources) Grid (Grid management, wLCG, NorduGrid, OSG, dGrid)
And therefore Schema. I may have missed a Schema out.
The Glue schema is a response to meet the existing demand for such a solution based on the current way of thinking. As grid infrastructures evolve and grid initiatives like EGI have more influence, we might see a paradigm shift which will require a change in Glue. However, before we started defining Glue 2.0, there were many discussions, including alignment with the OGF reference model, all of which have an infrastructure centric view.
Good point, but I see the need to define a index of services to facilitate derived schema, and consider resolving Glue into a series of Derived Schema from VO Service objects.
Our infrastructure centric view is just one of the views we are taking in Glue. Therefore I feel Glue better expressed for future uses as three standards at least. With the VO Service Object as the class common to all schema. Glue at this moment is not just infrastructure centric, but is also monitoring and modeling.
The problem highlighted is that VOs have there own vocabulary, naming and semantics that is important to them eg the wLCG Tier structures.
Yes I agree with you Laurence, and suggest that VO's such as wLCG and Nordu Grid should put their Monitoring Requirements in a separate schema and define how service discovery should be unified by, sharing a common VO-Object with the Schema for Service Discovery, but potentially not bound between schema.
I would see Monitoring as an area for a much richer schema than is provided by Glue currently. This is for good engineering reasons and to make things interoperable. Hopefully in time Monitoring service Summary output could be standardised to include availability metrics for a variety of service types and implementations.
However, this is specific to the VO and is something that does not need agreement. The VO is free to define there own vocabulary. The real problem is a technical one on how this information is used within an information system. For EGEE we have have evolved various mechanisms to do this, such as the FCR mechanism.
I was unaware of the FCR mechanism. For people who have not looked up what FCR mechanism is its a way so VO's can publish information.
Unfortunately Grid wide Monitoring within Glue is potentially changeable, this is why I want VO-Service Objects, and a clear statement that all services are expressed through VO-Service Objects. I feel that transforming Glue to a set of schema that share a common VO-Service Object will massively simplify the FCR mechanism for users and reduce potential tight coupling, and increase interoperability.
The danger of not embracing VO-Service objects is that we become unable to send users of Glue a clear way to describe resources consistently and briefly in their own schema as inherited objects as not all services are represented in a consistent way.
I fear the consequence of inconsistency of representation of physical entities with in Glue 1.0 and potentially Glue 2.0 will lead to dependent representations suffering greatly when accounting objects are redefined for example. This use case occurred between Glue 1.2 and Glue 1.3.
I am really happy that you bring up the idea of Glue 3.0! As I said in my previous mail Glue 2.0 is not the end but just the being. As we are currently finalizing the specification, this is the wrong time to revisit the discussions on the fundamental model. Over time and through the influence of EGI etc, we may see a shift in the fundamental model to which this group must respond.
I also share Laurence's fears about such a fundamental change as an entity relationship change, but to me the worry is that without re factoring to make the expression of an instance of a Storage element identical to that of the CE (which is I already a VO Service Object derivative) we will make work for users of the FCR and other Schema publishing methods that are used on Grids. If people are aware that the VO Service Object is the identifier of all services it, may well allow smoother progression to multiple Grid providing services.
Like Laurence and Sergio, but maybe for different reasons I want to focus on keeping Glue simple, for me this is best expressed as a series of sub schema all referencing a single VO Service Object Entity.
I hope Glue 3.0 can be at least 3 schema sharing the common concept of a VO-Service Object and specifying instances of services in terms of VO-Service Objects, for the benefit of interoperability and FCR users.
I agree this is too lofty a goal for Glue 2.0.
I feel that changing the schema's entity relations in that area has been done so recently its a shame the idea of presenting services in a consistent way has not been received clearly enough from me.
Since Glue is such a large effort, and has so many potential Grids as a target audience I feel Glue 2.0 could be improved immensely by simplification by this entity change and facilitate smother progression to Glue 3.0 with FCR users and similar communities.
Regards
Owen
participants (5)
-
Laurence Field -
Owen Synge -
owen.synge＠desy.de
-
Sergio Andreozzi -
Timo Baur