Choose timezone
Your profile timezone:
TMB Meeting
Description
A phone conference has been set up:
To dial in to the conference call:
Call: +41227676000 (Main)
Enter access code: 0170047.
To join the web conference, click here: https://audioconf.cern.ch/call/0170047.
To dial in to the conference call:
Call: +41227676000 (Main)
Enter access code: 0170047.
To join the web conference, click here: https://audioconf.cern.ch/call/0170047.
TCG minutes 19 Nov 2008.txt
Attendees
=========
Nick (minutes): SA1
Markus
Oliver (SA3)
Patricia (Alice)
Massimo
Chad
Cristoph
John W.
Francesco
Vangelis
Steven
Xavier
Mario
Jeff
Cal
Actions
=======
5401: Jeff. Should drop this and introduce item for correct deployment
of info providers at sites. All agreed that this should be closed.
5952: In progress. This will go into MSA3.7. Close this when the
milestone is ready.
6649: Waiting for final GLUE spec before this can be closed.
6652: Jeff: When will it be possible to corectly publish sub-clusters.
Oliver: Steve hopes that this will be ready be the end of the
year.
Jeff: Will it be possible to match sub-clusteer for specified
SpecInt?
Oliver: These changes will allow corect publishing, but matching
is another issue.
Will ask Steve to attend the next meeting to give an update.
6901: Waiting for first draft. Vangelis chasing them. Linked to 7841.
7187 & 7188: Frencesco has some feedback and forward this to Cecile.
Nothing from JRA1 though.
Markus: The presentation they gave suggests they can do complex
data mining and so maybe the dashboards team should be asked.
Masimo: This request is too broad. We need to understand better
what they want.
Markus: Do they take data feeds from grid services?
Markus: Should replace this with an action item for a
brainsorming session.
Cal: This was already done. We shouldn't repeat it.
Nick: No feedback from SA1 even after several requests.
Oliver: Please can JRA1 and SA1 update the task.
7675: In progress.
7676: PAtricia to update ticket with a comment that this should be
closed.
7678: SHould be closed (John W)
7941: Steve will give an update next meeting.
7932: Oliver: Is this compatible with the JRA1 work plan?
Francesco: Depends on which components. There is not enough
detail in the action.
Steven: JRA1 should update the ticket with what the current
work plan would provide. We will then discuss at the next meeting.
7943: Hydra clients are now in PPS. Close the task.
7945 & 7995: No progress.
8161: No progress. Close. To be handed over to Jeroen and the working
group.
8162: Accepted by Jeroen. Close.
Ask Jeroen to supply list of members by the next TMB.
8060: Francesco will update the ticket. Relies on GLUE2. However, there
is a field that can be used in the GLUE 1.3 schema.
Jeff: Can't publish all supported CAs for all services - this
will grossly inflate the info system.
Markus: Alternate solution would be to publish tags that
describe a set of CAs.
Oliver: How would matchmaking work with this?
Markus: Could resolve tag to a URL which lists the CAs.
DECISION: The TMB will decide on the sets to be created.
Francesco: Should we wait for GLUE 2 or start now? We will
discuss this off-line.
Oliver: Francesco to summarize and distribute for discussion at
the next meeting.
No further tasks were discussed due to time.
Authorisation service
=====================
See slides attached to the agenda.
* Background information on authorization service presenation
-----------------------------------------------
Jeff: What is the DPM model
Cristoph: use of virtual UIDs and GIDs derived from the DNs.
Markus: Direct read/write control wouldn't be handled in this way for
all storage elements. So DPM model can work for dCache and Castor but
not STORM.
* Authorization Service presentation
---------------------
Slide 2:
- It became clear that 2/3 sites cannot ban users, VOS, CAs in a timely
manner (<1 month).
- Just because a pilot job gets onto a site, doesn't mean that all
possible work brought in by the pilot should be allowed to run at the
sites.
Slide 3:
- Markus: Files created by commnad line tools should be manualy
editable.
Slide 4:
- Markus: The metrics to be acheived by the Auth service can be derived
directly from the performance requirements on the CE and WMS.
Oliver will provide the documents that give these details.
- Chad: Also need to come up with performance metrics for different
deployment scenarios (small sites using remote service, large site
running local service, etc.). Should SA1 come up with this?
Slie 5:
- Integration into WMS and CREAM will have to be done by those
development teams.
* Discussion of issues raised at EGEE 08
--------------------------------------
Points raised by Jeff:
- Jeff: Need to weigh up pros and cons. This is not an incremental
change but will require very significant change. Is it worth the pain?
- Jeff: Concern: system will pull in policies from the outside.
Chad: the remote policies will be viewed in plain text. Also, remote
policies will not be active just becuase they have been imported.
Jeff: So if the viewer app tries to view the policy and it is not
displayed properly by the viewer, the admin should ditch the policy?
Chad: yes.
Oliver: Can the system tell the admin what would be the result of a
test if they policy was applied?
Chad: No. You would need to apply it in a test environment and
actaully try it.
Markus: So for all policy changes, the site admin will have to be in
the loop. Wasn't one design goal for the VOs to be able to manage their
own policies?
Chad: When a policy is accepted by the admin it can be changed later
by the policy provider.
Markus: So there is no point in the admin checking the policy. Only
that they trust the policy provider?
Chad: yes.
Oliver: Does the VO policy take precedence over the local policy (if
it exists)?
Chad: Precendents can be configured.
Jeff: This is good, but makes understanding the implications of the
implementation of policies dificult. c.f. routing tables.
We need a default setup otherwise the flexibility of the system
will make it impossible to configure for admins of smaller sites.
Oliver: So we need an explicit statement on what is the default
behaviour if the site admin does nothing.
DECISION: It was agreed that the JSPG should set this.
Cristoph: Simplest scenaio is to have only a local policy. Next
simplest is to add 1 remote policy which would probably be the OSCT.
Other remote policies should be introduced with practical experience.
Markus: If in the next 1-2 years we only acheive the publishing of a
dynamic ban list, then this approach seems too complex.
Steven: One of the aims of EGEE 3 is to transition to EGI. Therefore
this seems a good solution for the longer term future.
MArkus: But if we take too long, people will implement their own
solutions and it will be almost impossible to move away from these. So
we should either be more aggresive in the implementation of this, or do
something simpler.
Markus: For WMS matchmaking, the WMS would need to contact all sites
to find the policy?
Chad: Either that or there needs to be a central store of policies
that can be referenced by the WMS.
Markus: What is estimate of JRA1 effort to enhance matchmaking for
this?
Francesco: Mostly already in the work plan. Not much extra needed.
Markus: So what is the estimate of when it can be provided (including
keeping performance)?
Francesco: Can't give a date now.
Markus: Need to know this before we can roll out this system.
Jeff: We need to see a detailed migration plan before we go further.
Markus: Agree.
Oliver: Cristoph and Chad will have discussions with SA1 and SA3.
Oliver: Does anyone see anything that means we need to change course?
DECISION: All agreed that this wasn't needed.
Cistoph: We will directly interact wth the DM people in parallel.
Markus: We also need to be clear what we expect will need to be done
after the end of EGEE III.
SUMMARY:
********
1) Need to be clear that implementing this approach gives sufficient
benefits to warant the pain of transitioning to it.
2) AuthZ working group need to discuss with SA1 and SA3 regarding what
the typical deployment and rollout scenarios might be. This will:
a) Allow the calculation of performance criteria that the
authorization framework will need to meet.
b) Allow the specification of which default local/remote policies
will be needed and their relative precedence - so that most common
deployment scenario(s) are covered by default and admins of small sites
won't need to carry out complex configuration. The detail here has to
come from the JSPG.
c) Encourange acceptance if a gradual rollout (of software and even
of policies) can be demonstrated which brings value at each stage.
3) Need to know when the WMS matchmaking will be able to use the new
authorization service. (-> Francesco)
4) The above information needs to be incorporated into a detailed
migration plan. This will need to show what work will need to done as a
sequence of events, indicating also what is likely to remain after the
end of EGEE III.
5) Clarification of what the Authorisation Service could bring to DM
will happen in parallel and will not be on the critical path to
deployment.
IPv6
====
Xavier agreed to put this off to the next meeting.
AOB
===
None.
Next meeting in 2 weeks.
There are minutes attached to this event.
Show them.