[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [gram-dev] BES
Dear All:
I'd like to see a resource estimate for BES support, along with the
related supporting work, so that we can think strategically about the
tradeoffs. I do think that several communities are going to be asking for
BES support.
Ian.
At 01:07 PM 9/17/2006 -0400, Jarek Gawor wrote:
So is there a decision about the
BES interface demo for SC? Because now with this WS-Addressing issue the
demo will require two people working on it....
IMHO, if BES will not be in 4.2 in production quality then we should not
worry about this demo and instead of focus on the performance issues and
on other things that we promised for 4.2.
Jarek
-----Original Message-----
From: owner-gram-dev@xxxxxxxxxx
[mailto:owner-gram-dev@xxxxxxxxxx]
On Behalf Of Ian Foster
Sent: Sunday, September 17, 2006 12:44 PM
To: Peter G. Lane; Peter G. Lane
Cc: Steve Tuecke; Ravi Madduri; gram-dev@xxxxxxxxxx
Subject: Re: [gram-dev] BES
Right, we need to have our solution for support of multiple interfaces in
place.
At 10:40 AM 9/17/2006 -0600, Peter G. Lane wrote:
I just realized that the BES spec causes some of the same problems with
GT as does adoption of OGSA WSRF Basic Profile. Specifically, BES uses a
different version of WS-Addressing than the GT uses. BES uses
"http://www.w3.org/2005/08/addressing"
while the GT uses
"http://schemas.xmlsoap.org/ws/2004/03/addressing".
Unless we upgrade our WS-A implementation, we won't be able to comply
with the BES spec.
Peter
Peter G. Lane wrote:
Steve Tuecke wrote:
So you are arguing that we do BES+JSDL as a prototype, and not include
either in 4.2? I would agree with that. I think adding JSDL
to the current GRAM protocol just adds another support and compatibility
issue. Let's stick with the current GRAM interface and job language
until BES and JSDL firm up before adopting them as a supported feature of
Globus.
This is what we originally agreed upon, but as I understood it there were
apparently people pushing for GRAM to have JSDL regardless (it at least
made converting to different job descriptions a little easier). Also,
part of this, again IIUC, was a fear that people would look elsewhere if
we didn't show something with standards. I never really knew who this
was, so somebody else will have to elaborate. I think if we participate
in this interop demo, that should take care of that. We also have the
problem that we've been telling people that JSDL support will be in 4.2.
The demo might also make up for this (especially if people can download
it and play with it), but I'm not as politically savvy as others here to
be certain of this.
Peter
-Steve
On Sep 16, 2006, at 10:00 AM, Peter G. Lane wrote:
Right, one of the reasons we decided against implementing BES for 4.2 was
the lack of resource to do it given our other priorities. Even if we do
it just as an SC demo, we're still taking valuable developer time away
from other things. If we're going to do this, I agree with Ravi that we
should not tack on JSDL support to the 4.0 interface. JSDL support was a
compromise between getting JSDL support out there soon and implementing
all of BES. I still believe just JSDL support is a minor step towards
interoperability, so telling people to download the demo code if they
absolutely must have JSDL support seems reasonable to me.
Peter
Ravi Madduri wrote:
I agree to this approach. I think we should think hard before we try to
implement a changing (?) spec and also on the hook to provide production
quality GRAM. We put in considerable amount of effort to make GT4 gram
implementation solid and changing some (or most of) it for 4.2 by
reimplementing it using BES ( and using JSDL underneath instead of JDD )
should be well thought out. I know we can probably use the same code
underneath the hood and just change the service interface but still i
think we should just implement a different service as a prototype that
supports JSDL/BES and have the current implementation be the production
implementation. In the next big release, we can deprecate the current
impl and make the JSDL one production quality
My 2c
Steve Tuecke wrote:
We might want to decouple a decision about doing a BES implementation for
the SC interop test, from the decision on whether to implement BES in
4.2. I would argue doing a prototype implementation for the SC
interop test make sense. But I would also argue that we should not
rush to put that into 4.2 -- let's keep it in a branch until BES is
finished and there are clear indications of adoption, then figure out
when to finish it, test it, move it into trunk, and release it in a
stable GT.
-Steve
On Sep 15, 2006, at 9:36 AM, Peter Lane wrote:
Yeah, I talked to Chris from Platform about this. I think it comes down
to what our priorities. We already decided not to implement BES for 4.2,
so doing so requires rethinking what we want to do for 4.2. We should
discuss this at our F2F in two weeks or have a phone call after with have
a concrete 4.2. feature list ready.
Peter
On Sep 14, 2006, at 10:39 PM, Ian Foster wrote:
Dear All:
I am told that people plan a BES "interop test" at SC.
(Actually, I think it may be rather a HPC Profile interop test, i.e., a
subset of BES.) The spec won't be finished by then but should be close.
It could be politically a good thing for us to participate. We should
look at what would be involved.
Ian.
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
0? *?H?÷
?0?10 +0? ¬10 +0â?¬
*?H?÷
?P0?¦0?? �0
*?H?÷ *â?
Hâ? ÷
0i10 â??&?â??ò,dorg10
â??&?â??ò,dDOEGrids1 s1 0UCertificate Authorities10U
DOEGrids CA 10
051111152456Z
061111152456Z0^10
â??&?â??ò,dorg10
â??&â??°â??ò,ddoegrids10
UPeople10UPeter G Lane 3642430?"0
*?H?÷
?0??»Ã?â???äÃ??Ã?<¹ÃM â??Ã?<¹ÃM
â?¹Ã?3¶é=?vU5âHÃ?ñz®w7¼Ah?Ã?Ã?Cñ;?Uâ??d¥°%óÂ?l?lñ?Ã?=Âhý??Ã?mE[w"é!Myâ??"c<?2n??[dÿÃ?¢fo®Â¢fo®°5¶an?WAoÂ?Ã?Ã?aé:YÂ??ñbx=Ã?Ã?4Ã?B©?"L5â??@`?Ã?Ã?Ã?Ã?©?Nk2Ã?û?ü°ÿ·Ã??ø·?=D`
Ã?¦9æÃ?³ù?oÂ?ÂË?oÂ?¸ðÃ?±Ã?ä1éÃ?¡Ã?Â??F?®r8"[])}QJn>Ã?uï¯j^¸[Ã?ÂÃ?½1¸?Ã?ç5Â?èfãIÃ?oÃ?Ã??~â??Ã?â?¹|CUäÃ?Ã?º?;ù?ùâ?¬Dy£c0a0
`?H?øBà 0Uÿð0U#0?�?n¤8]B�1��?1���
]0U0Â?lane@xxxxxxxxxxxx
*?H?÷
?|Ã?r
|Ã?r
?¹vçÃ?W29z¾MbÃ?óþÃ?ãsaTÃ?â??rÃ?x¶
±<ð<]@Ã?ggzñö#¬ûúÂ?Ã?Ã?â???pxÃ?Ã?¯f^b"Ã?â??cÃÂ?cX?>¡Ã?D"D"kPÃÂ?òëSÃ?Â??ú¾=æ#Q¼Ã?â?ºÃ¦Ã³hâ?º?é[?½¯´áá0{¡i
õ?â��ó¨¾?�<â
Â?<ü??W0Æ?Pdæ-±æ-±Ã?-Ã??â
â??ZÂ?}ÃÃ??*%D6¸=iSpJ|µ0rÃ?i'LKÃ?uOÃ?/l
Ã?ccÃÂ?Â?Æ?FÃ?*ëÃ?Ã?`c
äÃ?(¯¯â?`â??G®{©æÂ?Ã?>Ã??¾_Ã?÷4¯Ã?Ã?1÷ø
¦¢=ÿ9Ã?Jæð鸾ç0?¦0?? ÃŽ Ã?0
*?H?÷
0i10 â??&?â??ò,dorg10
â? â??&?â??ò,dDOEGrids1 0UCertificate
Authorities10U
DOEGrrids CA 10
051111152456Z
061111152456Z0^10
â??&?°â??ò,dorg10 â??&?â??ò,ddoegrids10
UPeople10UPeterr G Lane 3642430?"0
*?H?÷
?0??»Ã?ââ??â??»Ã?â???äÃ??Ã?<¹ÃM
â?¹Ã?3¶é=?vU5âHÃ?ñz®w7¼Ah?Ã?Ã?Ã?Ã?Cñ;?Uâ??d¥°%óÂ?lñ?Ã?=Âhý??Ã?mE[w"é!Myâ??"c<?"c<?2n??[dÿÃ?¢fo®°5¶an?WAoÂ?Ã?Ã?aé:YÂ??ñbx=Ã?Ãbx=Ã?Ã?4Ã?B©?"L5â??@`?Ã?Ã?©?Nk2Ã?û?ü°ÿ·Ã??ø·?=ø·Ÿ=D`
Ã?¦9æÃ?³ù?oÂ?¸ðÃ?±Ã?ä1éÃ?¡Ã?Â??F?®r8"[r8"[])}QJn>Ã?uï¯j^¸[Ã?½1¸?Ã?ç5Â?èfãIÃ?oÃ?Ã??~â??Ã?ââ?¹|CUäÃ?Ã?º?;ù?Dy£c0a0
`?H?øBà 0Uÿð0UUÿð0U#0?�?n¤8]B�1���
]0U0Â?lane@xxxxxxxxxxxx
*?H?÷
?|Ã?r
?¹vçÃ?W29z¾MbÃ?óþÃ?ãsaTÃ?ãsaTÃ?â??rÃ?x¶
±<ð<]@Ã?gzñö#¬ûúÂ?Ã?Ã?â???pxÃ?Ã?¯f^b"Ã?â??cÃÂ?cX?>¡Ã?D"kPÃÂ?òëSÃ?Â??ú¾=æ#Q¼Ã?â?ºÃ¦Ãóhâ?º?é[?½¯´á0{¡i
õ?âÃ?Ã?ó¨¾?Ã?<â Â
Â?<ü??W0Æ?Pdæ-±Ã?-Ã??â
â??ZÂ?}ÃÃ??*%D6¸=iSpJ|iSpJ|µ0rÃ?i'LKÃ?uOÃ?/l
Ã?cÃÂ?Â?Æ?FÃ?*ëÃ?Ã?`c
äÃ?(¯¯â?`â??G®{©æÂ?Ã?>Ã?¾_Ã?÷4¯Ã?Ã?1÷ø
¦¢=ÿ9Ã?Jæð°Ã©Â¸Â¾Ã§0?ø0?à 0
*?H?÷
0u10 â??&â
â??&â?°â??ò,dnet10 â??&?â??ò,dES10UESnet1
0UCertificatee Authorities10UESnet Root CA 10
021205080000Z
080110080000Z0i10
â??&?â??ò,dorg10 â??&?â??ò,dDOEGrEGrids1
0UCertificate Authorities10U
DOEGrids CA 10?"0
*?H?÷
?0??´õÃ#a£Ã?>fµ¸Â?o²?Ã?-Â?o²šÃ?-jmr¢?Ã?Âq÷¼+.Ã?Ã?câ,-ÿY"Ã?d
n1Ã?Ã?.kÃ?Ã??Ã??Ã?â??údÃ?´ë`Ã?â???
IÃ?wÃ??áQâ??HWKTo@lòyþúqÂ¥BÃ?Ã?~Â?!t.Â7â??«?8ôÃ?5ö^Ã?6ZÃ?Ã\ö·<Â5y9%?þgì²KÅKÅ?Ã?!k´Ã??Ã?Ã??_ú}!Ã?£Ã?ç|%Ââ??wÃ?ÃÆ?øÂ?cC¸vâ?vâ???Q[7?Ã?rÃ?oÃ?³µ?QýlW7¾?Ã?Ã??lpk?]-Æ?ðÃâ?-Æ?ðÃâ??ïcNÃ?ªæÃ?-tö«Ã?°Ã?Z®Æ?Ã?o«<¦¤@ºJ{Mø]Ã?{?êªROÃ?Ã??QZ)ùcw¯?K£Â??0Â?â?º0
`?H?øB?0UÿÃâ?¡0UÿÃ?0UÃ??n¤8]BÃ?1Ã?Ã?Â?
]0U#0?¼]MH/ø5â??Y«\?K>Ã?²Ã?²:ê0Uÿ0ÿ0%U0Â?DOEGrids-CA-1@xxxxxxxxxxxxx
*? H?÷
?*;b?>Â?3p{)5V#Æ?+±¶(=vÃ?â??53?¡¿(B7â xB7â
xQÂ{Ã?¤´`-#â??gÃ?Køj1q.ãë?8Ã?Ã?¶Ã?ðRa5Ã???j½?j½BF?¹Ã?Â?ãÃ?]=Ã?£3NQëji_g?kÃ?E´´ªxýÃ?^Ã?¸¿´þ¾BkêÃ?Ã?¹ñî¥@Ã?wè¨(v¶c¶â??JÃ?HÃ?dj?Â?Ã?1rI¥ÿ¿£°ôÃ?¥½Ã?Ã?
u<iû²@x1îÃ?Ã?¼¯?;DÃ?â??ê
©Zµkk;Â>Ã?z[½TÃ?ï<xG?¸-*Ã?#Ã?)eSÃ?½º
·±?ûþê�(�(ôü�Yy�§@é�Gf¢åÿ.#A»1?N0?J0o0i10
â??&?â??ðâ??ò,dorg10 â??&?â??ò,dDOEGrids1
0UCertificate Authoriities10U
DOEGrids CA 1�0 + ?´0 *?H?÷
1 *?H?÷
0 *?H?÷
1
060917 060917164010Z0# *?H?÷
1UÂ?Ã?0YÃ?«f8K?â?ºÂ®Â?üÃ?üÃ?ºâ??0R *?H?÷
1E0C0 *?H?÷
0*?Hâ? 0*â? Hâ? ÷
?0
*?H?÷
@0+0
*?H?÷
(0~ +?71q0
+â??71q0o0i10
â??&?â??ò,dorg10 â??&?â??ò,dDOEGrids1 s1
0UCertificate Authorities10U
DOEGrids CA 1Ã?0Â??*?Hâ Hâ? ÷
1q
o0i10
â??&?â??ò,dorg10 â??&&?â??ò,dDOEGrids1
0UCertificate Authorities10U
DOEGridds CA 1Ã?0
*?H?÷
?w¼?u==8âð=÷·ñ5]·Â·Ã±5]Ã??Ã
?]8Âá¢c$²ªâ????Ã?zO?gÃ??cj·µÂ?&!áÃ?*ÂáÃ?*·Mf¢õ?Ã?¦Â?YÂÃ??
l,ø=¨ã?B
±Ã?®û6Ã?Ã?ø?Ã?øÂ?~Ã?´?ÿhÃ?¢ ?â??çÃ?>
&ö<ð+¹PXëÃ?Ã?ºâ¡õKââ??.?6Ã?©ê?³.d?A*O8p?Ã?Ã?¼Â?ÿöÃ?´Ã?Ã?S½Â?ÂS½Â?¡ÂZ«0)X@¥ç¹Ã?sÃ?¢hð
)ôtñ»Ã?£>zùÃ?Z2©eJÃ?½??T=:¡('?é«»Ã?Â?ôÿ{;Ã?ósR<Ã?½¥~Ã?cÆ?VÃ?·94Ã?4Ã?'??½ü´Â?©?4
________________________________________________________________
Ian Foster -- Weblog:
http://ianfoster.typepad.com
Computation Institute:
www.ci.uchicago.edu
& www.ci.anl.gov
Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com
Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov
Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org