Hi all, and sorry for missing recent calls - was busy with other meetings. You probably converged to some consensus regarding profiling and new specifications during one of the calls I missed - if you did, could you please outline the result? If not, I'd like to compare pros and contras of each approach. Andrew's "minimal changes" document advocating profiling seems to be larger than the GES strawman itself; this makes me wondering what is the definition of a "minimal change", and where is the margin when it is more efficient to introduce a new standard? My major concern about profiling is that different profiles of the same standard may easily turn out to be incompatible, even if each was perceived as a "minimal change" by the authors. Then the very idea of standard compliance gets void. I would prefer to avoid ambiguity as much as possible. There may be little semantic difference between different profiles of the same standard and different standards, but it can cause large practical implementation and operational implications. Cheers, Oxana
Oxana Smirnova wrote:
Hi all,
and sorry for missing recent calls - was busy with other meetings.
You probably converged to some consensus regarding profiling and new specifications during one of the calls I missed - if you did, could you please outline the result?
Hi Oxana, during the last meeting Andrew described in detail his proposal: http://forge.ogf.org/sf/go/doc15630?nav=1 At the moment no consensus has been reached yet. Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
Hi,
during the last meeting Andrew described in detail his proposal:
http://forge.ogf.org/sf/go/doc15630?nav=1
At the moment no consensus has been reached yet.
I am not sure a consensus is needed. Gorbachev is famous for introducing this word into Russian vocabulary, and equally famous for failing miserably in reaching it, when the country he was leading simply collapsed under him. The word is hardly ever used since ;-) Let me go into another history lesson: take SGML. It is an overkill of a standard that no-one can practically implement, but it has the famous off-springs of HTML and XML, each of which is a *standard* in itself, not a profile or extension. There seem to be a tendency here to turn things up-side-down. And now to arts: Michelangelo said that to make a good statue one just has to chip off the unnecessary chunks; when it is Venus already, no matter how bad you chip away, you won't get David. Cheers, Oxana, not daring to continue with analogies
Oxana, The size of the documents is not indicative of the content. A good deal of the document is an attempt to succinctly extract the requirements from the GES document and give some background on the existing specs and profile. The only really substantive change to an existing specification is to BES - adding a new state, profiling sub-states (that have been discussed and documented before), and then describing how the existing specs (with the mentioned delta's) could be used to address the requirements. As an aside to the whole group. This next bit is rather embarrassing. I have not read the specification as published for some time (GFD.108). It turns out that my memory is not as good as I thought. First, the state model already includes Pending, and example profiles (but not formal profiles) for file staging, and suspend resume, are already in the document. Note that the createActivity takes an ActivityDocument which contains the JSDL, and has an extensibility point (element) that we could profile to include something like HOLD_PENDING (note that this is also where the document recommends subscriptions go as well.) Second, most operations ARE vector operations except for createActivity - which of course would need to become a vector operation as discussed. Third, notification subscription is already in the document - though it is a bit strangely put. Finally, it is not necessary to use RNS to get a list of activities, you can do that already using getFactoryAttributesDocument. We (the Genesis II team) recommend eliminating the ActivityReference element from the attribute document (it is a list of activity EPRs), and replacing that with RNS. We have found that for containers with a large number of contained activities, e.g., containers back-ended by PBS queues, that the size of the activities document grows out of control and rapidly leads to timeouts in the SOAP operation. Thus, the modifications are even less than I thought. A
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Oxana Smirnova Sent: Sunday, May 17, 2009 8:39 PM To: pgi-wg@ogf.org Subject: [Pgi-wg] Profiling vs new specs
Hi all,
and sorry for missing recent calls - was busy with other meetings.
You probably converged to some consensus regarding profiling and new specifications during one of the calls I missed - if you did, could you please outline the result?
If not, I'd like to compare pros and contras of each approach.
Andrew's "minimal changes" document advocating profiling seems to be larger than the GES strawman itself; this makes me wondering what is the definition of a "minimal change", and where is the margin when it is more efficient to introduce a new standard?
My major concern about profiling is that different profiles of the same standard may easily turn out to be incompatible, even if each was perceived as a "minimal change" by the authors. Then the very idea of standard compliance gets void.
I would prefer to avoid ambiguity as much as possible. There may be little semantic difference between different profiles of the same standard and different standards, but it can cause large practical implementation and operational implications.
Cheers, Oxana _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
hi, Andrew Grimshaw wrote:
It turns out that my memory is not as good as I thought.
First, the state model already includes Pending, and example profiles (but not formal profiles) for file staging, and suspend resume, are already in the document.
yes, those state examples caused some confusion, some groups though that those example states are actual BES recommendations :) I think the state model needs fixing (or call it extension) in order to be suitable for PGI.
Note that the createActivity takes an ActivityDocument which contains the JSDL, and has an extensibility point (element) that we could profile to include something like HOLD_PENDING (note that this is also where the document recommends subscriptions go as well.)
this is the kind of approach i don't really like: instead of introducing a clean extra input parameter you propose to squeeze everything into an extension of the ActivityDocument which i thought initially was just the "JSDL". There is a very similar approach all over BES. Things are not treated in a clean manner, there is quite an ambiguity around the ActivityDocument. bye, Balazs Konya
All, My response is
-----Original Message----- From: Balazs Konya [mailto:balazs.konya@hep.lu.se] Sent: Wednesday, May 20, 2009 5:11 AM To: Andrew Grimshaw; pgi-wg@ogf.org Cc: 'Oxana Smirnova' Subject: Re: [Pgi-wg] Profiling vs new specs
hi,
Andrew Grimshaw wrote:
It turns out that my memory is not as good as I thought.
First, the state model already includes Pending, and example profiles (but not formal profiles) for file staging, and suspend resume, are already in the document.
yes, those state examples caused some confusion, some groups though that those example states are actual BES recommendations :)
I think the state model needs fixing (or call it extension) in order to be suitable for PGI.
Note that the createActivity takes an ActivityDocument which contains the JSDL, and has an extensibility point (element) that we could profile to include something like HOLD_PENDING (note that this is also where the document recommends subscriptions go as well.)
this is the kind of approach i don't really like: instead of introducing a clean extra input parameter you propose to squeeze everything into an extension of the ActivityDocument which i thought initially was just the "JSDL".
[Andrew Grimshaw] This is exactly what the extensibility point is for, so that extra information can be agreed upon and profiled without requiring a new function to be defined every time an optional parameter is desired. Thus, a profile can be constructed along with a conformance claim and a service can advertise which profiles/conformance claims it supports.
There is a very similar approach all over BES. Things are not treated in a clean manner, there is quite an ambiguity around the ActivityDocument. [Andrew Grimshaw] There is no ambiguity around the ActivityDocument. As specified it has a JSDL document embedded. Anything else may or may not be used by the service.
bye, Balazs Konya
..my two cents if I understand both sides:
-> this is the kind of approach i don't really like: instead of introducing a -> clean -> extra input parameter you propose to squeeze everything into an extension -> of the -> ActivityDocument which i thought initially was just the "JSDL". -> -[Andrew Grimshaw] This is exactly what the extensibility point is for, so -that extra information can be agreed upon and profiled without requiring a -new function to be defined every time an optional parameter is desired. -Thus, a profile can be constructed along with a conformance claim and a -service can advertise which profiles/conformance claims it supports.
Here, "extra information can be agreed upon" is right - but when I understand it right it is exactly that we here don't like to support the "old relics / old way of doing it still" or carry it around although it's deprecated, and not provides backwards compatibility anyway, and is not intended to use by production middleware.... ...however in this sense, we may can profile "the old relics" out which point again to the question of how much we actually have to profile out / develop new. Take care, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Andrew Grimshaw -Sent: Wednesday, May 20, 2009 2:31 PM -To: 'Balazs Konya'; pgi-wg@ogf.org -Subject: Re: [Pgi-wg] Profiling vs new specs - -All, -My response is - -> -----Original Message----- -> From: Balazs Konya [mailto:balazs.konya@hep.lu.se] -> Sent: Wednesday, May 20, 2009 5:11 AM -> To: Andrew Grimshaw; pgi-wg@ogf.org -> Cc: 'Oxana Smirnova' -> Subject: Re: [Pgi-wg] Profiling vs new specs -> -> hi, -> -> Andrew Grimshaw wrote: -> > It turns out that my memory is not as good as I thought. -> > -> > First, the state model already includes Pending, and example profiles -> (but -> > not formal profiles) for file staging, and suspend resume, are already -> in -> > the document. -> -> yes, those state examples caused some confusion, some groups though that -> those -> example states are actual BES recommendations :) -> -> I think the state model needs fixing (or call it extension) in order to be -> suitable for PGI. -> -> > Note that the createActivity takes an ActivityDocument which -> > contains the JSDL, and has an extensibility point (element) that we -> could -> > profile to include something like HOLD_PENDING (note that this is also -> where -> > the document recommends subscriptions go as well.) -> -> this is the kind of approach i don't really like: instead of introducing a -> clean -> extra input parameter you propose to squeeze everything into an extension -> of the -> ActivityDocument which i thought initially was just the "JSDL". -> -[Andrew Grimshaw] This is exactly what the extensibility point is for, so -that extra information can be agreed upon and profiled without requiring a -new function to be defined every time an optional parameter is desired. -Thus, a profile can be constructed along with a conformance claim and a -service can advertise which profiles/conformance claims it supports. - -> There is a very similar approach all over BES. Things are not treated in a -> clean -> manner, there is quite an ambiguity around the ActivityDocument. -[Andrew Grimshaw] There is no ambiguity around the ActivityDocument. As -specified it has a JSDL document embedded. Anything else may or may not be -used by the service. -> -> bye, -> Balazs Konya - - -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg
participants (5)
-
Andrew Grimshaw -
Balazs Konya -
Moreno Marzolla -
Morris Riedel -
Oxana Smirnova