Choose timezone
Your profile timezone:
PTB Meeting
→
Europe/Zurich
lund.room.1 (Teleconference)
lund.room.1
Teleconference
Description
PTB meeting, 10-12:00, 4 September 2012
Calling details: skype
Proposed agenda:
----------------
- coming releases
- follow up on review recommendations
- security area status
- standard compliance testing (its is a KPI!)
- EGI Technical Forum in Prague
- aob
PTB meeting, 10:07 - 12:06, 4 September 2012, on skype
Present: Balazs, Laurence, Patrick, John
Excused: Jon, Cristina,
not showed up: Marco
i) releases
a) Cristina posted the usual release manager report on scheduled EMI release updates both for EMI 1 and EMI 2:
https://dl.dropbox.com/u/34258911/ptb_reports/PTB_report_04_09_2012.pdf
PTB agrees with the planned EMI-1 and EMI-2 updates.
The report also presents a change in the release cycle, 3-week-long cycles are introduced.
PTB endorses the suggestion to change change the release cycle to 3 weeks.
b) The release coordinator also prepared the EMI 3 preparation roadmap:
https://dl.dropbox.com/u/34258911/reports_varie/montebianco-v.1.doc.pdf
The plan was discussed and approved by the PTB. In particular, the 26th October deadline for the release candidate of base components were highlighted.
Later during thew meeting the issue of Y3 development not to be release within EMI 3 came up. Patrick mentioned that some dev tasks will run after code freeze, especially in the data area (e.g. FTS3, Storage federation). These features are NOT planned to be released in EMI. Balazs supports such development nevertheless he will ask for a PEB approval. The area leaders are asked to identify such post EMI 3 dev tasks from the tracker.
ii) follow up on review recommendations
- Balazs starts with quoting from the report:
"it is frustrating in the extreme that the missed milestone is related to infrastructure security. Security is becoming crucial to the successful and
trustworthy usage of IT infrastructures and should not be deployed on top of an existing technical architecture; it should have been integrated in the fundamental architecture at the beginning, not put on top of what exists at the end of the project."
Balazs things that the reviewers got it wrong because EMI do have a security architecture, it exists, it is coherent and solid. It is just not written down therefore the reviewers got the wrong impression that all EMI security is an add-on, adhoc solution base around a delayed STS product.
John disagrees, he thinks there is no such things as common EMI security architecture. At the moment three slightly overlapping world exits (unicore vs. glite+arc). The early agreement to base common EMI security on VOMS including some openening up towards SAML AND on the new STS product was not achieved.
Regarding VOMS, unfortunately Unicore discovered technical challenges that requires the usage and integration of a non-production ready componenent (ARGUS-EES).
Regarding STS, that products development was extremely delayed by its developers being tied down on other tasks of other products (ARGUS), also third party dependencies delayed the work. Furthermore, priority decisions were not directly communicated down to the developer and to the affected product teams and collaboration partners.
because of all this, John thinks it is difficult to write down an EMI security architecture, the maximum we can have is the description of the three mw stack security. Balazs does not agree. He thinks that EMI do have an integrated security framework/architecture around x509/VOMS/ARGUS. This "architecture" was captured early in the EMI tech objectives.
conclusion: we are very far from being able to converge/complete the sec area milestone.
- Balazs quotes the recommendation f "Focus on security". It is agreed that John will present the security area status and plans on the next PTB.
- Recommendation h), to produce a technology roadmap, was discussed in detail
PTB agrees that this work should be a minimal effort, PTB should avoid duplication with other project's similar work. Agreed to wait at least until the CB decides on EMI collaboration future and until EMI-3 release materializes. Everybody mentions the large uncertainty. Balazs proposes to start the work in January/February but there'll be some preliminary discussion already at the EMI all-hands. Few of us worried that there is danger that at the end the document becomes an incoherent collection of product team plans.
- Finally, the recommendation (mentioned at several places) to scope down EMI dev tasks were brought up. Lower priority tasks that have no real chance to be completed may be cancelled.
one of the related recommendation texts:
"scope may need to be refined. Quality must not suffer merely to improve quantity."
iii) security area status
John will come with area overview that covers status, issues and next steps for the next PTB meeting. He should also present his view on the EMI security architecture, including topics like how STS and other "new" developments modify/extend the "architecture"
iv) standard compliance testing (its is a KPI!)
Balazs calls attention towards the standard compliance testing that is captured/measured by a KPI.
A collection of available and planned standard tests are available here:
Test suits:
https://twiki.cern.ch/twiki/bin/view/EMI/StandardComplianceTestSuites
Intensive discussion took place regarding how to run those tests, who should coordinate/monitor the test executions. Patrick suggests SA2 to take coordination/monitoring role.
Balazs mentions that some tests are yet to be written. These will be assigned to teams after the code freeze and expected to be written in November/December.
v) EGI Technical Forum in Prague
Following representations will take place, per area:
security: STS presentations in several sessions, dedicated security session
infra: information system and accounting workshops
data: no data this time at EGI-TF
compute: no idea, Marco was not present
vi) aob
- Jon will be away in September. Dedicated JRA1 meetings will be called to follow the progress on key development topics.
- Hydra turned out to be unofficially distributed (non-certified). missing documentation is the main showstopper.
- all-hands meeting
People complains about unclear messages around this event. It was not announced. Program is also questionable. It basically looks as an extended CB meeting wrapped in lots of free discussion time. Area leaders were asked to come with session proposals to fill the lots of available time slot.
- Balazs asked Patrick/John/PTB about the e-irg data blue paper, whether EMI should comment on it. Patrick will come back with feedback, if necessary, Balazs will ask for deadline extension (it was 5th September).
- next meeting: 25th September
ACTIONS:
-------
- area leaders: come with tasks (from the dev tracker) that are planned to be continued after the code freeze and NOT planned as EMI 3 release.
- Discuss the security area status at the next PTB meeting. The area leader will present status, plans, problems.
- area leaders to send session proposal for F2F meetings at the Budapest all-hands. deadline: next week Monday
- area leaders: check lower priority tasks in the tracker and indicate if something to be closed down.
- Balazs: asks for an extension to give feedback on the data blue paper IF Patrick comes back with a concrete date proposal and intention to provide EMI feedback.
Present: Balazs, Laurence, Patrick, John
Excused: Jon, Cristina,
not showed up: Marco
i) releases
a) Cristina posted the usual release manager report on scheduled EMI release updates both for EMI 1 and EMI 2:
https://dl.dropbox.com/u/34258911/ptb_reports/PTB_report_04_09_2012.pdf
PTB agrees with the planned EMI-1 and EMI-2 updates.
The report also presents a change in the release cycle, 3-week-long cycles are introduced.
PTB endorses the suggestion to change change the release cycle to 3 weeks.
b) The release coordinator also prepared the EMI 3 preparation roadmap:
https://dl.dropbox.com/u/34258911/reports_varie/montebianco-v.1.doc.pdf
The plan was discussed and approved by the PTB. In particular, the 26th October deadline for the release candidate of base components were highlighted.
Later during thew meeting the issue of Y3 development not to be release within EMI 3 came up. Patrick mentioned that some dev tasks will run after code freeze, especially in the data area (e.g. FTS3, Storage federation). These features are NOT planned to be released in EMI. Balazs supports such development nevertheless he will ask for a PEB approval. The area leaders are asked to identify such post EMI 3 dev tasks from the tracker.
ii) follow up on review recommendations
- Balazs starts with quoting from the report:
"it is frustrating in the extreme that the missed milestone is related to infrastructure security. Security is becoming crucial to the successful and
trustworthy usage of IT infrastructures and should not be deployed on top of an existing technical architecture; it should have been integrated in the fundamental architecture at the beginning, not put on top of what exists at the end of the project."
Balazs things that the reviewers got it wrong because EMI do have a security architecture, it exists, it is coherent and solid. It is just not written down therefore the reviewers got the wrong impression that all EMI security is an add-on, adhoc solution base around a delayed STS product.
John disagrees, he thinks there is no such things as common EMI security architecture. At the moment three slightly overlapping world exits (unicore vs. glite+arc). The early agreement to base common EMI security on VOMS including some openening up towards SAML AND on the new STS product was not achieved.
Regarding VOMS, unfortunately Unicore discovered technical challenges that requires the usage and integration of a non-production ready componenent (ARGUS-EES).
Regarding STS, that products development was extremely delayed by its developers being tied down on other tasks of other products (ARGUS), also third party dependencies delayed the work. Furthermore, priority decisions were not directly communicated down to the developer and to the affected product teams and collaboration partners.
because of all this, John thinks it is difficult to write down an EMI security architecture, the maximum we can have is the description of the three mw stack security. Balazs does not agree. He thinks that EMI do have an integrated security framework/architecture around x509/VOMS/ARGUS. This "architecture" was captured early in the EMI tech objectives.
conclusion: we are very far from being able to converge/complete the sec area milestone.
- Balazs quotes the recommendation f "Focus on security". It is agreed that John will present the security area status and plans on the next PTB.
- Recommendation h), to produce a technology roadmap, was discussed in detail
PTB agrees that this work should be a minimal effort, PTB should avoid duplication with other project's similar work. Agreed to wait at least until the CB decides on EMI collaboration future and until EMI-3 release materializes. Everybody mentions the large uncertainty. Balazs proposes to start the work in January/February but there'll be some preliminary discussion already at the EMI all-hands. Few of us worried that there is danger that at the end the document becomes an incoherent collection of product team plans.
- Finally, the recommendation (mentioned at several places) to scope down EMI dev tasks were brought up. Lower priority tasks that have no real chance to be completed may be cancelled.
one of the related recommendation texts:
"scope may need to be refined. Quality must not suffer merely to improve quantity."
iii) security area status
John will come with area overview that covers status, issues and next steps for the next PTB meeting. He should also present his view on the EMI security architecture, including topics like how STS and other "new" developments modify/extend the "architecture"
iv) standard compliance testing (its is a KPI!)
Balazs calls attention towards the standard compliance testing that is captured/measured by a KPI.
A collection of available and planned standard tests are available here:
Test suits:
https://twiki.cern.ch/twiki/bin/view/EMI/StandardComplianceTestSuites
Intensive discussion took place regarding how to run those tests, who should coordinate/monitor the test executions. Patrick suggests SA2 to take coordination/monitoring role.
Balazs mentions that some tests are yet to be written. These will be assigned to teams after the code freeze and expected to be written in November/December.
v) EGI Technical Forum in Prague
Following representations will take place, per area:
security: STS presentations in several sessions, dedicated security session
infra: information system and accounting workshops
data: no data this time at EGI-TF
compute: no idea, Marco was not present
vi) aob
- Jon will be away in September. Dedicated JRA1 meetings will be called to follow the progress on key development topics.
- Hydra turned out to be unofficially distributed (non-certified). missing documentation is the main showstopper.
- all-hands meeting
People complains about unclear messages around this event. It was not announced. Program is also questionable. It basically looks as an extended CB meeting wrapped in lots of free discussion time. Area leaders were asked to come with session proposals to fill the lots of available time slot.
- Balazs asked Patrick/John/PTB about the e-irg data blue paper, whether EMI should comment on it. Patrick will come back with feedback, if necessary, Balazs will ask for deadline extension (it was 5th September).
- next meeting: 25th September
ACTIONS:
-------
- area leaders: come with tasks (from the dev tracker) that are planned to be continued after the code freeze and NOT planned as EMI 3 release.
- Discuss the security area status at the next PTB meeting. The area leader will present status, plans, problems.
- area leaders to send session proposal for F2F meetings at the Budapest all-hands. deadline: next week Monday
- area leaders: check lower priority tasks in the tracker and indicate if something to be closed down.
- Balazs: asks for an extension to give feedback on the data blue paper IF Patrick comes back with a concrete date proposal and intention to provide EMI feedback.
There are minutes attached to this event.
Show them.
The agenda of this meeting is empty
