Steve, Concerning OGF PGI Session 1 at OGF 33 on Tuesday 20 September 14:00-15:30 : Thank you very much for your 'Draft Minutes' : They are readable, understandable and quite accurate. I suggest following improvements : - For project representations, could you add EDGI Etienne Urbah [EU] ? - I did NOT say 'three diagrams about this state model', but 'three sequence diagrams about the endpoint for job management'. Thank you in advance. Best regards ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Wed, 21/09/2011 11:14, Steve Crouch wrote:
14:00-15:30 PGI Session 1 -------------------------
[These are draft minutes, please respond with revisions/comments from those present]
Project representation; - IGE Steve Crouch (SC) - SAGA Andre Merzky (AM) - EMI Jon Kiier Nielsen (JKN) - XSEDE, Genesis II - A Grimshaw (AG) - RENKEI Katzushige Saga (KS) - UNICORE (who was representative here?) - QCG-Computing Marius Mamonski (MM) - EDGI Etienne Urbah [EU]
[Is this list complete?]
Minutes: Steve Crouch
New actions:
[AG] will write a description on the differences between these two approaches (new port type, or on EPR)
Minutes
AG: One big spec or multiple specs/iterations? What should we do?
SC: Not one big spec. 200 reqs in one spec would not be scalable in terms of developments and very impractical. AG agrees - just too difficult.
DW: we don't have all spec experts required in the room to put into this. Not enough represtnation. We shoulnd't do this.
DK: any other representatives that should be here?
AG: 5th F2F PGI meeting - stakeholders have come in and out over time. Some big groups (interested in a big spec) have been represented here quite a bit.
AG: do we start with what we have, or start again? We can leverage what our experiences and what is there if we go with what is there.
AM: should be split the work into various areas with various specs?
AG: agreement to use GLUE2 resource properties, replace in JSDL resource properties - Etienne. BES: PGI wanted state model changes (primary thing wanted), vector operations (I see as trivial). Job management - JSDL for description, BES for management. GridFTP, Byte/IO, put these play into how the data is managed in JSDL - a secondary concern.
EU: HPC file staging - ppl interested in how to specify file staging.
AG: we want to do this, do we change for JSDL or not. Also the SPMD, ParamSweep profile.
EU: we should reuse where possible, where no problems exist with doing so.
AG: big difference in profiling and extending JSDL, than doing something new (new namespaces, whole doc, etc). Do tweaks and profiles where possible.
AG: look at using existing specs, and building on these, rather than restarting - a consensus?
DW: EGI virtualisation TF is all about profiling existing specs.
Alan E Sill: for security group fully intends to take what works, what exists, working fast using this approach.
[Consensus agreed on doing]
AG: PGI in Catania - we can agree on func bits forever, but security has to work too. Don't drop security on the floor
JJ: need to find right people to engage with the security ???? group, to develop in areas that overlap with PGI.
AES: PGI needs to state clearly what needs to be done to handoff to other groups for the work.
AG: take existing PGI work, as inputs to the process. Authn/z/delegation pass to security group. We have 2 profiles for delegation, for each style of delegation: message-level delegation (SAML assertions) and transport layer. Problems in PGI - not much compromise possible with security, people wouldn't change transport level and vice versa (hence two profiles).
AES: all authz implementations use SAML or XACML.
AG: not always - e.g. Genesis II uses ACLs.
AES/JJ: profile work to decide on SAML assertion for VO-using sites that internally s/w does its own thing.
AG: transport of auth mechanism already profiled in WSI-BSP. Semantics need to be profiled. Orthogonal for Access Control policy; that's completely site dependent.
DW: security not original focus, what's desired session outcome?
AG: decide on move forward on modifying existing specs - have consensus here. Continue along the JSDL/BES path. Or reject, and go another way. If we use BES - 2 approaches. 1) change state machine to meet requirement to hold jobs at various data-related stages; 2) history about BES - some historic bad decisions, should we revisit those decisions. You get EPR back, subsequent management done through factory port type - some thought one service. Rexamining this would mean changing this.
EU: three diagrams about this state model - is there a bottleneck on only one endpoint? BES issue. I did NOT say 'three diagrams about this state model', but 'three sequence diagrams about the endpoint for job management'.
DM: interested in param sweeping. don't drop it.
DW: writing profiles.
AG: agree on work items for group.
DW: we should have experiences doc on interop work done so far?
AG: already written - SC.
AG: - data staging FSE+ - param sweep - state model extensions (getstatus) - vector ops - JSDL changes
EU: many of these profiles already exist - should we build on them or make something different?
AG: motion to change JSDL to reflect JSDL group changes in resource profiling (through GLUE2).
DW: we need something coherent and whole, would like to see something that fits all things all together e.g. GLUE fits with BES fits with JSDL. With this top-level doc referencing other profile docs.
DM: some work needs to be done to move towards this position first.
DW: agreed.
AES: e.g. CDMI interesting as a spec for this standpoint.
DW: Virtualisation session - everything broken up into smaller parts. But we keep revisiting this, but need to approach this sensibly so it all comes together again at the top.
MM: extension related to BES used in production(?) - how to deal with this?
EU/AG: PGI use cases and requirements analysis done last year - painful.
EU: moving forward, pick one of the above listed items.
AG: jsdl changes need to be done, really want to do data staging. BES without data staging is more or less useless. You need to understand protocols.
DM: can we bring up faults in JSDL data staging?
AG: yes, perhaps in next session?
AG: need new working group chairs decided in Salt Lake City - Michel Drescher, Andrew Grimshaw.
AG: what problems are people having with BES? We changed it support RNS (small change).
MM: change - added things to factory attributes. Manual data staging, other changes.
AG: have manual staging as a separate interface.
Might want activity status achieved through one resource, but forces one service to take all requests.
AG: leap into JSDL stuff (not good, JSDL have their own ideas), or leap into BES stuff - e.g. status requests through a single endpoint.
AM: should go through requirements made to PGI.
AG: for BES - manual data staging. Current state model says you can't make new states, only substates. PGI req from some members stated that job could be submitted, but in blocked state until explicit 'go' telling it to move into next state. Support through new port type.
AM: add a new port type - don't break it badly.
Some clients wouldn't know about suspend/resume substates.
EU: full suspend/resume state model is complicated.
AG: define new port type which defines what happens for each substate in BES. Circulate this idea. Have this as a compliance target in one of the uber-high level profiles.
DM: mentioned already in OGSA-DMI - would be good for us.
EU: existing state model of BES good enough to be profiled. But we need a valid state change from Pending to Failed.
AG: one other thing - to get to PGI use case, have it going from Pending to Running:Suspended initially. We would need to do a little bit more changes for this. JSDL might not like it but, can put it in a JSDL element to state 'suspended'. But not a clean way since JSDL should only be a job description, not management.
AG: motion - we will use this basic state model, ask JSDL to include 'start in this suspended' state, or new port type tht controls states a job is in.
DM: yes, becuase being able to suspend and resume at off peak times would be useful for OGSA-DMI.
AG: ok, we define a new port type with suspend and resume. It is resolved! It will have 'suspend' with an EPR (or a vector of EPRs), and similarly 'resume' with an EPR (or vector of EPRs).
EU: this relates back to the recent PGI requirements doc I wrote for these requirements.
AM: ppl will complain hold and suspend mean same thing.
AG: suspend is at BES level, hold gets put in JSDL.
EU: rename hold as suspend?
DW: it'll do whatever LRMS supports at back end. Which support hold?
EU/AG: if it can't do suspend, it faults.
AG: could put suspend/resume on the activity itself. Instead of new port type on BES, instead call on EPR to have
Action [AG]: will write a description on the difrerences between these two approaches (new port type, or on EPR)
AG: feels like we've made good progress today!
DW: those who are not here should have limited voice.
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg