Possible convergence between VAPOR and VO Operations Dashboard
→
Europe/Paris
phone conference
phone conference
,
Minutes of meeting: Possible convergence between VAPOR and VO Operations Dashboard
In introduction, I3S makes a short presentation of the objectives of VAPOR, as described in the list of features: https://wiki.egi.eu/wiki/VT_VAPOR:VAPOR_features_description
It is agreed that integrating VAPOR features within the VO Operations Dashboard makes sense for several reasons:
CC makes a presentation of the main technical concepts in VO Operations Dashboard:
Lavoisier service:
A main component of the VO Operations Dashboard is the Lavoisier service: it is a data aggregator, able to integrate data from heterogeneous sources, making mash-ups using advanced data parsing and aggregation functions, providing a cache that seamlessly protects services relying on Lavoisier from failures of other data sources.
Lavoisier data sources are integrated as plugins, and lots of such plugins already exist: web service (GGUS), LDAP (BDII), XML (GOCDB), JMS (Nagios), relational databases, and others.
It is rather easy to integrate new data sources and produce mash-ups. Lavoisier 2 (tests on-going, to be released) even provides web display features to present the data in various representations and charts. Nevertheless starting up with Lavoisier usage and plugins developments requires face to face meetings.
=> Lavoisier could be used to integrate new monitoring data described in VAPOR, either by reusing the biomed support tools that collect monitoring data as new data sources, or by replacing them as the data collected may already be fully available (BDII and GOCDB connectors for instance). In the latter case, the exploitation of the monitoring data acquired could be implemented as a new plugin of Lavoisier.
Web layer:
Tthe VO Operations Dashboard uses the Symphony php framework, and will shortly migrate to Symphony 2. Symphony 2 is designed to allow for the development of independent components, that can be integrated separately. All components can rely on the same base components to perform usual tasks such as relational of NoSQL database access layer, users authentication and access control, etc.
In this context, and if I3S wishes to acquire skills in the Symphony framework (learning curve not neglectable though), VAPOR features may be developed as independent components integrated in the dashboard.
In the features addressed by VAPOR, the community users management (database, users life cycle) is probably the one that needs to be discussed in details: it involves a user life cycle workflow, interactions with external systems that are not just data retrieval (LFC, EGI Applications Database, VOMS)
Actions:
- I3S starts to investigate what APIs are available for the systems that VAPOR has to interact with(beyond simple data retrieval that may be handled by Lavoisier: LFC, EGI Applications Database, VOMS.
- Flavien starts to check Symphony 2 tutorials, also look at Sylex (spelling ?)
- CC checks the features specified in VAPOR to have a better idea and provides feed back if necessary.
- I3S provides CC with a description of the existing monitoring scripts of biomed.
- CC provides a feed back as to how these could be integrated into/implemented as Symphony 2 components.
- Schedule a 2 days face-to-face meeting beginning of June to dig into more technical discussions.
In introduction, I3S makes a short presentation of the objectives of VAPOR, as described in the list of features: https://wiki.egi.eu/wiki/VT_VAPOR:VAPOR_features_description
It is agreed that integrating VAPOR features within the VO Operations Dashboard makes sense for several reasons:
- This would complement existing functions of the dashboard with more specific admin and operation tasks.
- This would avoid to make yet another portal for VO managers, and provide them with an all-in-one integrated portal.
- In parallel, the VO Operations Dashboard welcomes new features with the restriction that (i) the features fit with the goals of the portal, and (ii) the implementation follows the approach of components, integrable and testable separately. Additionally, this integration can help increase (already great!) popularity of the VO Operations Dashboard.
CC makes a presentation of the main technical concepts in VO Operations Dashboard:
Lavoisier service:
A main component of the VO Operations Dashboard is the Lavoisier service: it is a data aggregator, able to integrate data from heterogeneous sources, making mash-ups using advanced data parsing and aggregation functions, providing a cache that seamlessly protects services relying on Lavoisier from failures of other data sources.
Lavoisier data sources are integrated as plugins, and lots of such plugins already exist: web service (GGUS), LDAP (BDII), XML (GOCDB), JMS (Nagios), relational databases, and others.
It is rather easy to integrate new data sources and produce mash-ups. Lavoisier 2 (tests on-going, to be released) even provides web display features to present the data in various representations and charts. Nevertheless starting up with Lavoisier usage and plugins developments requires face to face meetings.
=> Lavoisier could be used to integrate new monitoring data described in VAPOR, either by reusing the biomed support tools that collect monitoring data as new data sources, or by replacing them as the data collected may already be fully available (BDII and GOCDB connectors for instance). In the latter case, the exploitation of the monitoring data acquired could be implemented as a new plugin of Lavoisier.
Web layer:
Tthe VO Operations Dashboard uses the Symphony php framework, and will shortly migrate to Symphony 2. Symphony 2 is designed to allow for the development of independent components, that can be integrated separately. All components can rely on the same base components to perform usual tasks such as relational of NoSQL database access layer, users authentication and access control, etc.
In this context, and if I3S wishes to acquire skills in the Symphony framework (learning curve not neglectable though), VAPOR features may be developed as independent components integrated in the dashboard.
In the features addressed by VAPOR, the community users management (database, users life cycle) is probably the one that needs to be discussed in details: it involves a user life cycle workflow, interactions with external systems that are not just data retrieval (LFC, EGI Applications Database, VOMS)
Actions:
- I3S starts to investigate what APIs are available for the systems that VAPOR has to interact with(beyond simple data retrieval that may be handled by Lavoisier: LFC, EGI Applications Database, VOMS.
- Flavien starts to check Symphony 2 tutorials, also look at Sylex (spelling ?)
- CC checks the features specified in VAPOR to have a better idea and provides feed back if necessary.
- I3S provides CC with a description of the existing monitoring scripts of biomed.
- CC provides a feed back as to how these could be integrated into/implemented as Symphony 2 components.
- Schedule a 2 days face-to-face meeting beginning of June to dig into more technical discussions.
There are minutes attached to this event.
Show them.
The agenda of this meeting is empty
