[Pgi-wg] meeting notes from OGF29?
Johannes Watzl
watzl at nm.ifi.lmu.de
Thu Jul 1 18:53:15 CDT 2010
Hi Balazs, all,
below the notes from the sessions and the workshop (day 1) in Chicago. I
have been to Italy for another meeting the last days.
Morris has taken notes from the second day - I was editing the document.
Best,
Johannes
PGI session 1, OGF29, Chicago
participants: Morris, Johannes, Kazushige, Etienne, Aleksandr, Michaela,
Mark, Wolfgang Ziegler, Andre
indtroduction round
poster by Etienne
starting with requirements list
1:
Andrew disagreed
XML rendering before GLUE
Alexander:
bring to GLUE
Morris:
lack of people in the GLUE group
talking with them about timelies
agreement
###
3:
Etienne:
related to GLUE
Mark:
control heterogehous resources
Etienne:
differenece betwee execution service and endpoint which is just a queue
Aleksandr:
numerous endpoints
Mark:
endpoint GLUE specific?
Aleksandr:
no
Mark:
endpoint means epr?
then completely disagree
Etienne:
if you have one WS-addressing
Alex:
why do we want to bind ourselves to an addressing service?
Mark:
just an example
Etienne:
GLUE totally agnostic about the transport mechanism
XML description of the endpoint
Aleksandr:
no accessity for this requirement
Morris, all:
refining the requirement; depicting structure of requirement to make clearer
discussion about GLUE endpoint homogenous vs. heterogenous
changing to:
A GLUE endpoint can describe only one job submission interface (e.g. BES).
Job submission interfaces which have different properties must be captured
by separate GLUE computing endpoints.
agreement
###
9:
Mark:
why prohibit anonymous execution
Aleksandr:
every service should require encrypted connection
personally vote no
changing to X.509 on TLS (mandatory option, allowing others)
Alex:
not seeing why it is necessary
agreement
###
10:
Mark:
why limit to IGTF
Aleksandr:
out of scope
Morris:
out of scope
out of scope
###
11:
proceed with 12
###
12:
Morris:
would drop it
out (too general)
###
13,14,15,16:
out (just options)
###
17:
Etienne:
can we propose that it must accept one of the X.509 proxies, Full X.509)
Morris:
difficult to agree on in that sense
Aleksandr:
should note that SAML is just a syntax
Etienne:
who really requires SAML?
SAML out of scope because of its complexity
agreement
###
18:
out (it is a policy)
###
24:
Aleksandr:
out
because its up to the implementation
postponed, no agreement
###
25:
postponed
###
26:
postponed
###
27:
out (practically impossible)
###
33:
Morris:
meta model
always contact them first
not defined, assumed
Aleksandr:
deep negative impact on interoperability
Etienne:
either must be an information service providing security information for
endpoints
or endpoint must provide its own security info through public interface
postponed
#################################################
Session 2:
38-41:
Etienne:
do not agree with current title
requirement for security audits
Mark:
logging must be kept
Morris:
rename to
logging information must be kept and must be made available
out of scope (remotely logging is out of scope)
Mark:
make statement: logging is out of scope of PGI
efforts in JSDL activity instance
###
42:
Mark:
implementation detail
strongly disagree
Morris:
out
Etienne:
relationship with the GLUE model
out (too strict)
###
47:
Mark:
out
out (not in accordance in distributed systems design)
###
48-54:
Etienne:
execution service must stay always the same
rename
Mark:
why requiring?
Etienne:
implication on what is a job id
Mark:
what job id is is a specification
postponed
###
55:
Mark:
it is a definition not a requirement
renaming
PGI does not deal with job workflows, job collections
agreement
###
56,57:
agreement
###
58:
Morris:
out bacause collcetions are out of scope
Wolfgang:
how do you define collections
Morris:
jobs with one common id
change to "should not"
agreement
###
59:
Aleksandr:
think we do not need this requirement
Etienne:
we must state what is in and out of scope of PGI
###
60:
duplicate to 55
###
69:
postponed
####################################################
session 3:
70:
no, don't need filters
###
71:
out (complementary efforts in JSDL activity)
###
72:
Aleksandr:
about extensible state
Morris:
one mandatory state model - PGI model
but other models based on this
Mark:
not going to do state model substating like BES does?
Aleksandr:
parallel stating, not substating
Morris:
not the intetion in this requirement
Mark:
reword it
yes
###
73:
Etienne:
complex queries, vote no
execution service should be as simple as possible
Morris:
not needed
out (not needed)
###
74:
Morris:
could rephrase it
Mark:
talking about getting the list of activities
yes
###
75:
Etienne:
execution of the job can be completely opaque to the user
user never interacts with the job
out (manual data staging required)
###
76:
Aleksandr:
just opposite of 75
Etienne:
if I am only one, then yes. don't want to block group agreement
yes
###
77:
out (implied in 76)
###
78:
Morris:
different understanding of the states
Mark:
definitely agree with this requirement
Etienne:
propose to rephrase the requirement
Aleksandr:
should we have this in requirements
yes
###
79:
yes
###
80:
Aleksandr:
would vote yes
rephrase to suspend
yes
###
82:
Aleksandr:
some elements should be allowed to be ignored
Mark:
create optional requirement within JSDL
yes
###
83:
yes
###
84:
Mark:
we disagree
part of original BES spec, common use case for us
you could just not use it
rephrase
Mark:
potential value add for GENESIS
yes
###
85:
Etienne, Kazushige:
no, because of complexity
Morris, Mark:
should be optional
Aleksandr:
how define finished state?
rephrase
yes
###
87-89:
postponed
#####################################
PGI Workshop after OGF29, Chicago
participants:
Morris, Aleksandr, Michaela, Kazushige, Johannes, Mark, John, Giuseppe,
Andre
90:
Morris:
who voted no?
yes
91:
Michaela:
contradiction to 90?
Mark:
91 you have to do it before you create activity
Aleksandr:
you cannot return id
Mark, Morris:
like 92 more
execution service should have control over it
Morris:
92 is on top of 90
91,92 out
###
93:
rephrase
Mark:
requirement is out, should be downgraded to may or can
Etienne:
if we want this requirmenet we have to describe it
vote, majority needs it
Aleksandr:
could implement it as an extension
###
95:
Mark:
implementation details
Morris:
out, because non-functional
###
96:
Etienne:
related to the model of stability of the endpoint
Morris:
get an idetifier back that points to the second
Mark:
if activity migrates around you don't have to track
WS-naming is the answer
Etienne:
sequence diagram
Morris:
does not need to be an epr
Aleksandr:
if you migrate
different services may choose different ways to create eprs
postponed
###
97:
postponed
###
98:
Morris:
seems to also go into this direction
Etienne:
still vote no
in order to keep the client simple
Morris:
no
postponed
###
99:
Morris, Etienne:
duplicate to 84
###
103:
Morris:
would say yes
Etienne:
would vote no
agreement on yes
###
104:
Aleksandr:
don't know if it is a requirement
Etienne:
would like to change some into any
yes
###
105:
Aleksandr:
101 duplicate/subset of 105
yes
###
106:
skip, postponed
###
109:
Morris:
structure needs to be somehow more GLUE
John:
equivalent of cleaning up BES
yes
###
110:
Mark:
what is the real requirement here?
Aleksandr:
ranges of JSDL
better description or simpler structure
Mark:
we should not go too far away from JSDL
this would break compatibility
Giuseppe:
how would PGI effect JSDL
Mark:
official response from JSDL: they welcome extensions
Morris:
it is our task
currently we are only at the ranges
Aleksandr:
ranges are most confusing structure in JSDL
we should do it in order to avoid confusion later
Etienne:
current sentence is a statement not a requirement
Morris:
rephrase
who says yes?
two yes
who says no?
two no
postponed
###
111:
Etienne:
more precise understanding?
out, softwareengineering design principle
###
112:
Morris:
who is voting no?
yes
###
113:
postponed
###
115:
postponed
###
117:
Mark:
seems a little out of scope
out (not required)
###
126:
Aleksandr:
we have in ARC but nobody really uses it
Etienne:
not require it strongly, but some users need it
yes
###
127:
Etienne:
my interpretation
logs of activity must be kept to permit security audits
Mark:
execution service cannot keep logs forever
Aleksandr:
if service wants to purge job
it should keep some intermediate state remembering only the id
Mark:
yesterday decided logging and bookkeeping is out of scope
Morris:
rephrase it
Etienne:
would vote no
Morris:
who is saying yes
postpone
###
129:
out
###
130:
out (implementation specific)
###
132:
Mark:
rephrase, default state should not be hold
Morris:
targetting the time after creating activity
yes
###
133:
Morris:
someone saying no?
Etienne:
yes, because much too complicated
yes
###
134:
agreement - yes
###
135:
out (too vague)
###
136:
Mark:
reword
duplicate
###
137:
Etienne:
if you request hold points then the execution service should say if
holdpoints are accepted or not
137,138,139,140:
out
###
141:
Morris:
duplicate?
John:
141, 142 seem already be handled
duplicate
###
143:
Mark:
maybe listed as discussion starting point
we should agree on some subset protocols
Morris:
rephrase
keep as an example
###
151:
out (already agreed)
###
153:
postponed
###
155:
out (non-functional)
###
157:
Etienne:
would vote no becaus XML specific
Mark:
should use global Grid namespace
out
###
161:
out
###
162:
out (too specific)
###
163:
out, duplicate
###
164:
out, duplicate
###
167,168:
out (too specific)
###
170:
andre:
can be different ways, also state
out
agreement on:
no more reproposals
#######################################################
afternoon session
participants:
Joel, Etienne, Aleksandr, Mark, Andre, Johannes, Morris, John, Kazushige
Morris:
how to proceed?
Etienne:
go for the problem of stability of service endpoint and activity id
Morris, Mark:
activity id too complex to discuss
Morris:
dedicate person to requirment
Mark:
everybody should have the chance to prepare and look over the others
11:
Etienne:
everybody has to agree on GLUE
let us use the type
use GLUE as foundation
discussed
agreed to yes
###
24:
Mark:
we must have a common way for clients to authorize agreed upon
not to use one of x,y,z
Morris:
we would need a security expert
can try to talk to EMI experts
is Duane available, made good work
Mark:
not any more
question
makes sense to list the options
24,25,26:
Morris writes 1 page
Etienne:
currently European providers not use SOAP
###
33:
Morris,Mark:
assumed is a bit weak
agreement: out (not in scope)
###
48-54:
Morris:
volunteers?
different understandings
Etienne:
3 ways
initial endpoint is also responsible to manage it until the activity is
finished and forgotten
disadvantage: the single endpoint for whole activity duration becomes a
bottleneck
Aleksandr:
no
Etienne:
advantage: activity id can be completely opaque
Aleksandr:
we don't have activity id defined
Morris:
my proposal would be Etienne prepares a one page document
Etienne:
look at the diagrams to undestand
Aleksandr:
was already discussed on the mailing list
we have different approaches doing things
the spec we are going to produce should accept all the ways
Etienne:
already sent input
Expert input - Etienne
cover also 168
###
69:
out (implementation specific)
###
87:
Expert 1 page (Luigi)
###
88,89:
Morris:
routing and forwarding completely different
drawn 3 or 4 pictures already
Etienne:
do not understand these two and why they are different
must be completely transparent to the client
Aleksandr:
don't see requirement here
Etienne:
publish through different computing endpoints
Aleksandr:
just statements
Morris:
we should have these request routing capabilities
Expert 1 page (Morris)
Aleksandr, Etienne:
deployment question
###
96,97,98:
96: Expert 1 page (Etienne)
97,98: Expert 1 page (Morris)
andre:
understand the options
why is it a requirement
why user should be able to contact end of the path?
###
196:
Morris:
Mark?
John:
who needs it?
Aleksandr
Expert 1 page (Aleksandr)
###
110:
Expert 1 page (Mark)
###
113:
Etienne:
executable is defined by the path
propose to replace arguments by list of arguments
Expert 1 page (Aleksandr)
###
115:
Expert 1 page (Aleksandr)
Mark:
remember the discussion on the telecon
couple of things
it was extremly clear
some people disagre strongly
Etienne:
what means scalable time?
Mark:
which benchmarks?
Andre:
your backend understands what benchmarks mean, Aleksandr?
Aleksandr:
yes, if benchmark published then in can
John:
mandatory?
Etienne:
there is some mail exchange by Etienne and Oxana
Morris:
point Aleksandr to these mails
Joel:
least common denominator
musts and mays
andre:
could go to JSDL and post extension point
Morris:
change BES, JSDL,...
Joel:
strong desire of Etienne. Is it an absolute must?
Morris:
list mixed musts and mays
Joel:
it is always a good idea to do the absolute musts first
###
127:
Expert (Aleksandr)
###
153:
Mark will do it
###
168:
already assigned to Etienne
###
Morris:
go into the mays and musts
Joel:
maybe some musts could be changed to shoulds each of the production Grids
implement
Morris:
too many mays the spec will be useless
andre:
right, but otherwise maybe hard to implement
Morris:
go through to priorize
###
1:
Morris:
merge 1 and 2
2 is duplicate of 1
extend 1
Andre:
you will update PGI profile when new version of GLUE comes out?
Morris:
get rid with "most recent"
rephrase 1
###
Etienne:
first must define terminology, state model
Andre:
cannot define a state model out of the blue
Mark:
iterative process
Joel:
planned output
several options:
one doc
several docs?
Morris:
one PGI profile
several specs that will come out?
Joel:
show use cases that you would like to address
show me the PGI use cases
with separate document with use cases easier to agree
easier to iterate on
Morris, Andre:
not really time to create use case document
Joel:
would make sense to have it, but lack of time and manpower
Mark:
we are not time bound
Joel:
if each production Grid infrastructure provide their top use cases and then
share with each other and take half of a phone call
what's trying to be solved
Mark:
explain where did the requirements come from
Andre,Johannes:
requirements come from use cases
Mark:
many requirements go with one use case
let everybody produce use cases
bring together
Joel, Mark:
ist there a use case for the requirement?
Morris:
use cases
Joel:
having the mapping use case - requirment would help bringing in the other
players
Morris:
tomorrow?
Etienne:
go through vocabulary wiki
Mark:
benefit referencing the OGSA glossary
GFD 120
Am 01.07.10 12:38, schrieb Balazs Konya:
>
> Hi PGI,
>
> I heard from the nordugrid people that many things had happened during the
> productive OGF29 sessions. I was wondering if meeting notes containing decisions
> are available somewhere? Or the decisions are implicitly contained in the google
> document?
>
>
> bye,
> Balazs
> _______________________________________________
> Pgi-wg mailing list
> Pgi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
>
--
_ _ _ _ _ _ Johannes Watzl
|\/| |\ | |\/| Institut für Informatik / Dept. of CS
| | | \| | | Ludwig-Maximilians-Universität München
======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany
Room E 005, Phone +49-89-2180-9162
Munich Network Management Team Email: watzl at nm.ifi.lmu.de
Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl
More information about the Pgi-wg
mailing list