Choose timezone
Your profile timezone:
PTB Meeting
→
Europe/Zurich
Teleconference
Teleconference
Description
PTB meeting, 14:00-16:00, 26 October, 2010
Calling details: skype test conferencing service in Lund (call mailmagnes in skype)
Screensharing: https://my.dimdim.com/arc-emi (12345)
Proposed agenda:
----------------
14:00 - 14:10 Approval of previous meeting notes, follow up on actions
14:10 - 14:20 Architecture figure: status, updates
14:20 - 15:00 Data area architecture for EMI Final
15:00 - 15:30 Logging and Bookeeping service: area change?
15:30 - 16:00 AoB
PTB regular meeting, 26/10/2010, 14:00-16:06
Present: Laurence, Patrick, Marco, Balazs (notes)
Invited (from 15:00): Ludek and Zdenek representing L&B product team
Excused: John, Morris
1) Approval of previous meeting notes
- Meeting notes of 3.8.2010, 4.8.2010 and 14.9.2010 had become approved on 29 September.
- Meeting notes of 28.09.2010, 5.10.2010 are approved on this meeting.
2) Follow up on Actions
* Morris to start the process of "populating" the accounting task force: PENDING
The accounting task force needs to be bootsrapped, initial EMI plans on accounting records and publishers (both data and compute) need to be presented in Prague.
* Balazs to inform the PEB and directly the SA2 leader about the "configuration" agreement of PTB: DONE
The configuration decision was even communicated at the EGI-PTB.
* PTB to review task forces at the next PTB meeting after the F2F: PENDING
Sceduled for next meeting.
3) Architecture figure: status, updates
Desperately waiting for figure cleanup. Some suggestion arose to use different "representation" for our architecture. No conclusion.
4) Data area architecture for EMI Final
The following architecture changes should be applied to the figure:
* add namespace_if new internal component to DPM, StorM, dCache and LFC. Link all of these to Message broker. (this change addresses the synchronization)
* add emi_datalib as a replacement to every component where gfal or libarcdata2 appears (the common datalib phases out those). add emi_datalib to UAS-Data.
* Add a link between ARGUS and Dcache, DPM, Storm, LFC, FTS
* replace the SRM interface of SEs with two new inteface boxes: SRM (https), delegation-data. Change the EMI-0 figure as well, replace SRM with SRM (httpg).
* add new interface to all the SEs: NFS4.1(pNFS)
5) Logging and Bookeeping service: area change?
Balazs informed L&B team how the L&B topic came up: As part of the architecture drawing process the L&B service was discovered not to be a proper "infrastructure" service, rather a service mostly relevant for compute area. As of EMI-0, the L&B is only used by glite compute services and clients. Unfortunately, the EMI workplan is not really clear when it comes to L&B future role in EMI.
Laurence: The current L&B use-case falls under compute area, L&B is not spreading multiple areas.
A real infra area services should provide service for multiple areas. The use cases for L&B outside of compute area are not clearly understood, especially when it comes to user requirements.
Ludek told PTB that initially, during the proposal preparation phase, the L&B were considered as a more general service e.g. to serve data and other area services too. L&B was envisioned as general "event processing/collecting service".
Balazs commented that such a general L&B role was not clearly visible in the current workplans, it might be in the DoW, however it is not that explicit. The current tech workplans and EMI objectives do not attribute such a central role for the L&B service. It doesn't mean it couldn't be changed. It is just not there.
Patrick questioned the role of L&B once a general messaging service is available.
Some discussion about a concrete use case: sandbox tracking, tracking the data transfer of a job.
Balazs tried to summarize the discussion: the L&B use case in computing is more or less understood, for the other areas requirements should be collected describing how L&B as a general event logging service could be utilized.
Laurence commented on that 7 years of L&B EDG/EGEE presence was not enough to understand use cases for L&B as a general service, then the EMI 2.5 year will not be sufficient either.
Patrick: there is no manpower in data area to utilize an L&B as a "general event service"
Ludeck's proposal: L&B team will come with a collection of use cases and requirements for using L&B as a "general event processing service" in other areas than the computing area. The use cases should contain the source of the requirement (e.g. which user community needs such a functionality).
Discussed and agreed that L&B is not for accounting.
Ludek states that L&B is prepared to use the common EMI messaging once it is available.
Marco's question: Will there be a general message archive in EMI? Or EMI messaging is just about sending/receiving messages? Question to be further discussed at EMI messaging workshop in Prague
Conclusion of the one hour discussion: the original proposal to move the L&B PT from infra area to compute is postponed for the next PTB meeting. The PTB needs more info concerning user/community requirements to develop and use L&B as a general purpose event processing/recording service.
6) AoB
- next PTB meeting: in two weeks, 9th November.
fixed agenda items: decision about the L&B area move, task force overview, compute area architecture
- all hands: technical discussion topics are being collected, Balazs will post a list of topics the area blocks should address. Some of the topcs should go to "plenary", that is to non-parallel block.
ACTIONS:
* Morris to start the process of "populating" the accounting task force
* PTB to review task forces at the next PTB meeting after the F2F
* Morris: to make progress with the architecture figure
Present: Laurence, Patrick, Marco, Balazs (notes)
Invited (from 15:00): Ludek and Zdenek representing L&B product team
Excused: John, Morris
1) Approval of previous meeting notes
- Meeting notes of 3.8.2010, 4.8.2010 and 14.9.2010 had become approved on 29 September.
- Meeting notes of 28.09.2010, 5.10.2010 are approved on this meeting.
2) Follow up on Actions
* Morris to start the process of "populating" the accounting task force: PENDING
The accounting task force needs to be bootsrapped, initial EMI plans on accounting records and publishers (both data and compute) need to be presented in Prague.
* Balazs to inform the PEB and directly the SA2 leader about the "configuration" agreement of PTB: DONE
The configuration decision was even communicated at the EGI-PTB.
* PTB to review task forces at the next PTB meeting after the F2F: PENDING
Sceduled for next meeting.
3) Architecture figure: status, updates
Desperately waiting for figure cleanup. Some suggestion arose to use different "representation" for our architecture. No conclusion.
4) Data area architecture for EMI Final
The following architecture changes should be applied to the figure:
* add namespace_if new internal component to DPM, StorM, dCache and LFC. Link all of these to Message broker. (this change addresses the synchronization)
* add emi_datalib as a replacement to every component where gfal or libarcdata2 appears (the common datalib phases out those). add emi_datalib to UAS-Data.
* Add a link between ARGUS and Dcache, DPM, Storm, LFC, FTS
* replace the SRM interface of SEs with two new inteface boxes: SRM (https), delegation-data. Change the EMI-0 figure as well, replace SRM with SRM (httpg).
* add new interface to all the SEs: NFS4.1(pNFS)
5) Logging and Bookeeping service: area change?
Balazs informed L&B team how the L&B topic came up: As part of the architecture drawing process the L&B service was discovered not to be a proper "infrastructure" service, rather a service mostly relevant for compute area. As of EMI-0, the L&B is only used by glite compute services and clients. Unfortunately, the EMI workplan is not really clear when it comes to L&B future role in EMI.
Laurence: The current L&B use-case falls under compute area, L&B is not spreading multiple areas.
A real infra area services should provide service for multiple areas. The use cases for L&B outside of compute area are not clearly understood, especially when it comes to user requirements.
Ludek told PTB that initially, during the proposal preparation phase, the L&B were considered as a more general service e.g. to serve data and other area services too. L&B was envisioned as general "event processing/collecting service".
Balazs commented that such a general L&B role was not clearly visible in the current workplans, it might be in the DoW, however it is not that explicit. The current tech workplans and EMI objectives do not attribute such a central role for the L&B service. It doesn't mean it couldn't be changed. It is just not there.
Patrick questioned the role of L&B once a general messaging service is available.
Some discussion about a concrete use case: sandbox tracking, tracking the data transfer of a job.
Balazs tried to summarize the discussion: the L&B use case in computing is more or less understood, for the other areas requirements should be collected describing how L&B as a general event logging service could be utilized.
Laurence commented on that 7 years of L&B EDG/EGEE presence was not enough to understand use cases for L&B as a general service, then the EMI 2.5 year will not be sufficient either.
Patrick: there is no manpower in data area to utilize an L&B as a "general event service"
Ludeck's proposal: L&B team will come with a collection of use cases and requirements for using L&B as a "general event processing service" in other areas than the computing area. The use cases should contain the source of the requirement (e.g. which user community needs such a functionality).
Discussed and agreed that L&B is not for accounting.
Ludek states that L&B is prepared to use the common EMI messaging once it is available.
Marco's question: Will there be a general message archive in EMI? Or EMI messaging is just about sending/receiving messages? Question to be further discussed at EMI messaging workshop in Prague
Conclusion of the one hour discussion: the original proposal to move the L&B PT from infra area to compute is postponed for the next PTB meeting. The PTB needs more info concerning user/community requirements to develop and use L&B as a general purpose event processing/recording service.
6) AoB
- next PTB meeting: in two weeks, 9th November.
fixed agenda items: decision about the L&B area move, task force overview, compute area architecture
- all hands: technical discussion topics are being collected, Balazs will post a list of topics the area blocks should address. Some of the topcs should go to "plenary", that is to non-parallel block.
ACTIONS:
* Morris to start the process of "populating" the accounting task force
* PTB to review task forces at the next PTB meeting after the F2F
* Morris: to make progress with the architecture figure
There are minutes attached to this event.
Show them.
The agenda of this meeting is empty