- pgi-wg - lists.ogf.org

F2F workshop anybody?
by Oxana Smirnova 19 Mar '09

19 Mar '09

Hi all, after digesting all the threads, I came to a conclusion that we'd need more F2F workshops like the one at CERN. There was even an idea to have one before OGF25, but it didn't work because many didn't feel like doing transcontinental trips too often. Now that OGF25 is behind, shall we find a good date and place for an F2F session? Lund is best in spring and is nicely located 50km away from the Copenhagen airport; alternatively, NDGF premises are located 800 meters from the above mentioned airport. Cheers, Oxana

4 3

PGI TelCon 2009-03-13 Meeting Minutes available for Comments
by m.riedel＠fz-juelich.de 19 Mar '09

19 Mar '09

Hi PGI team, as having no secretary today I drafted (not necessarily complete) minutes, which are available in GridForge: http://forge.gridforum.org/sf/discussion/do/listPosts/projects.pgi-wg/discu… Please feel free to comment on the miuntes. More precise actions in preparation for the telcons will follow ASAP. Take care, Morris -------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel(a)fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.' ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

7 15

Re: [Pgi-wg] Discussion about elements/priorities in the field ofsecurity
by m.riedel＠fz-juelich.de 18 Mar '09

18 Mar '09

Howdy partners, (1a) > > If we are talking about attributes carried inside SAML > assetion, getting > > the attributes from attribute authority is not a challenge, for > instance we > > can use the VOMS SAML service (client gets back SAML assertion that > > including attributes through SSL authentication with VOMS SAML > service) as a > > candidate. Well I propose that we MAY have to consider also the classic VOMS style in using the Proprietary VOMS protocol to obtain ACs, because of interoperability reasons since many of our infrastructures (i.e. ARC + EGEE) rely on this - or am I wrong in this? Please consider that we have to focus on production not what may arise in 2 years time as a security framework. More conrete facts/questions: GENESIS-II and UNICORE will work with SAML-based VOMS because of largely build in support for SAML assertions. Q: Is there a short-time plan that ARC will be able to support SAML-based VOMS? Q: Is there a short-time plan that gLite will be able to support SAML-based VOMS? (1b) > I propose that the "aquisition of tokens" in a push-style model is > orthogonal to action-item (1). If we want to consider it, we > should address > it as a separate concern (in the same vein that > aquisition-of-delegation-tokens has been broken out into a > seperate issue). > Action-item (1) should be about nothing more complicated than > profiling a > simple request-response message exchange between two endpoints in > which all > parties already possess the necessary credentials. I agree with Duane - having both discussed together is too complex and certain elements of it are also part of a security document which in OGF public comment I guess: https://forge.gridforum.org/sf/sfmain/do/downloadAttachment/projects.ggf-ed… I suggest that we... a) create for this a seperate number in the thread which is 6 then b) re-use elements of the security groups we are working with, i.e. the above mentioned document and others. (1c) > > But how to push the SAML assertion from client side to service > side could > > be a challenge (for which voms has not provided solution, IMO). > I can see > > two ways: one ways is put the SAML assertion into X.509 proxy > certificate's> extension, by which you can gurantee that the > attributes information is > > binded with SSL authentication; > > > > I believe that the use-case for attribute-bound SSL authentication > involvesX.509 attribute certs (ACs) as per the original VOMS > implementation rather > than SAML attributes. > > > > the other way is to put SAML assertion in the SOAP header, which > > furtherly cause two branches: First brach, using the SAML > assertion for > > message (SOAP) level authentication + attribute carraying (in > this case the > > VOMS SAML service should probably be improved to creat SAML response > > containing a holder-of-key authentication assertion, then this > assertion can > > be used for message level authentication according to WS- > Security SAML Token > > profile 1.1); Second branch, using SAML assetion only for attribute > > carraying (in this case, the transport level securiry should be > configured).> I have been contributing to the SAML-based VOMS via OMII-Europe by being the first using it...:-) So the idea in 2006 was to use WS-Security Extensions in SOAP Headers with n SAML Assertions. CAS of Globus works with SAML assertions inside proxies to largely support Shibboleth and SLCs. However here I would strongly disagree to put this into PGI. I know no infrastructure using it directly like that. (2) > Yes. The Strawman doc makes an initial stab at this by profiling a > FQAN-style syntax/semantics for both X.509 ACs and SAML > assertions. (VOMS > already does that for the former, and the SAML examples in Morris' > doc in > GridForge resemble the latter.) That way both assertion-styles > would be > capable of conveying identical information. Yeah - but of course, we should explicitly make a list and come to an agreement between all of our members. So, it looks we have identified the security experts from GENESIS-II, ARC, and UNICORE - so we could need an expert of gLite too for Friday. Thanks for sharing your thoughts. Take care, Morris ----- Original Message ----- From: Duane Merrill <dgm4d(a)virginia.edu> Date: Tuesday, March 17, 2009 4:29 pm Subject: Re: [Pgi-wg] Discussion about elements/priorities in the field of security > Comments inserted.... > > 2009/3/17 weizhong qiang weizhongqiang(a)gmail.com > > > > > If we are talking about attributes carried inside SAML > assetion, getting > > the attributes from attribute authority is not a challenge, for > instance we > > can use the VOMS SAML service (client gets back SAML assertion that > > including attributes through SSL authentication with VOMS SAML > service) as a > > candidate. > > > > I propose that the "aquisition of tokens" in a push-style model is > orthogonal to action-item (1). If we want to consider it, we > should address > it as a separate concern (in the same vein that > aquisition-of-delegation-tokens has been broken out into a > seperate issue). > Action-item (1) should be about nothing more complicated than > profiling a > simple request-response message exchange between two endpoints in > which all > parties already possess the necessary credentials. > > > > But how to push the SAML assertion from client side to service > side could > > be a challenge (for which voms has not provided solution, IMO). > I can see > > two ways: one ways is put the SAML assertion into X.509 proxy > certificate's> extension, by which you can gurantee that the > attributes information is > > binded with SSL authentication; > > > > I believe that the use-case for attribute-bound SSL authentication > involvesX.509 attribute certs (ACs) as per the original VOMS > implementation rather > than SAML attributes. > > > > the other way is to put SAML assertion in the SOAP header, which > > furtherly cause two branches: First brach, using the SAML > assertion for > > message (SOAP) level authentication + attribute carraying (in > this case the > > VOMS SAML service should probably be improved to creat SAML response > > containing a holder-of-key authentication assertion, then this > assertion can > > be used for message level authentication according to WS- > Security SAML Token > > profile 1.1); Second branch, using SAML assetion only for attribute > > carraying (in this case, the transport level securiry should be > configured).> > > The second branch you describe ("bearer" style) is not viable: you > need a > "holder-of-key" approach in which the caller demonstrates > possession of a > private key corresponding to the public one signed into the > attribute by the > attribute authority. (You could potentially demonstrate this via > an SSL > signature, but I consider that to be an ugly hack and explicitly > discouragedit in the Strawman document.) > > Thus we arrive at two scenarios: ACs-via-SSL-authn and SAML-via- > SOAP-authn. > Confidentiality and integrity provided in both cases by SSL/TLS, > of course. > > > > > (2) Agreement on Definition/Semantics/Structure of Attributes > > > > > > Yes. The Strawman doc makes an initial stab at this by profiling a > FQAN-style syntax/semantics for both X.509 ACs and SAML > assertions. (VOMS > already does that for the former, and the SAML examples in Morris' > doc in > GridForge resemble the latter.) That way both assertion-styles > would be > capable of conveying identical information. > > Cheers, > > Duane > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

Re: [Pgi-wg] Scientific Computing - Integrating Service and Desktop Grids - Standardization
by Etienne URBAH 18 Mar '09

18 Mar '09

Jesus, Thank you for your study on my proposal to use Restricted Proxies permitting that untrusted computing resources from Desktop Grids have restricted access to storage resources of Service Grids. Compared to the current situation of unrestricted proxies which could be completely revoked, I do NOT understand how embedded read/write attributes could trigger any NEW revocation issue. EDGeS is also actively working on data storage by Desktop Grids. In particular, XtremWeb already provides it. The whole security model still has to be defined, and must be thoroughly reviewed. AFAIK, our EDGeS project considers that each Cloud provider has created its own closed proprietary environment and refuses any interoperability, so we are NOT planning to work about interoperability with Clouds. For video conferences, our MCU server is ccmcu40.in2p3.fr But I have NOT planned a video conference yet. Please note that the OGF26 date has changed : - OGF26 (Chapel Hill, NC, USA) 26-29 May 2009 Best regards. ---------------------------------- Etienne URBAH IN2P3 - LAL Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Mob: +33 6 22 30 53 27 Skype: etienne.urbah mailto:urbah@lal.in2p3.fr ---------------------------------- On Wed, 18 Mar 2009, Jesús Luna wrote: > Dear Etienne, > > First of all I'd like to excuse myself for this late reply to your email, however I'd like to let you know that there has been a change in my affiliation and since February I'm working with Barcelona Digital (an R+D center located in Barcelona, Spain). Nevertheless I still keep my interest in participating with EDGeS, in particular when referring security/privacy aspects. > > I've reviewed your proposal about potential use of Restricted Proxies and IMHO it's a nice approach for solving part of the trust issues that arise when bridging Service+Desktop Grids, however I'd like to comment the following: > > -A mechanism able to provide up-to-date Restricted Proxy's validation at the Trusted Node might be required to avoid potential security gaps related with the propagation of revocation information (i.e. updating read/write attributes or even revoking the whole Proxy). This issue was studied at OGF's CAOPS WG a couple of years ago (in fact I was part of that WG). > > -As a CoreGRID fellow, last year I was researching potential use of Desktop Grids for storing data (something I called a Desktop Data Grid). A paper was presented at the PCGrid'08 workshop (I met Peter there). Are you considering also this potential use as part of EDGeS project? If so, then we should review the proposed approach as Storage Nodes would be untrusted in this new scenario. > > -Finally, are -EDGeS- you planning to do some work about Cloud+Desktop Grid's interoperability? Maybe a position paper? > > Thanks again for taking into account my opinion and please keep me informed about forthcoming videoconferences. > > Regards, > > JESUS LUNA GARCIA > Security Researcher > M. 618 213 212 > jluna(a)bdigital.org > BARCELONA DIGITAL CENTRE TECNOLOGIC > Sancho de Avila 110-130, 08018 Barcelona > Tel. 93 553 45 40 - Fax. 93 553 45 41 > www.bdigital.org > > > > > > >> -----Mensaje original----- >> De: Etienne URBAH [mailto:urbah@lal.in2p3.fr] >> Enviado el: miércoles, 28 de enero de 2009 17:32 >> Para: J. LUNA >> CC: Peter KACSUK; Oleg LODYGENSKY; edges-na3(a)mail.edges-grid.eu >> Asunto: Scientific Computing - Integrating Service and Desktop Grids - >> Standardization >> >> Hi Mr. LUNA, >> >> >> In the domain of scientific computing, I am working with Peter KACSUK >> of MTA SZTAKI (Budapest, Hungary) inside the EDGeS project >> http://www.edges-grid.eu/ which is bridging >> Service Grids (Production Grid Infrastructures, like EGEE) with >> Desktop Grids (loose opportunistic grids using idle resources, like >> BOINC, XtremWeb, OurGrid). >> >> For the rationale, you can look at the text at the bottom of this mail. >> >> >> By now, our project, and other projects listed below, provide bridges >> in real operation between Service Grids and Desktop Grids. >> >> In order to provide world wide support of the growing computing needs >> of scientific communities, it is now time to : >> - bring together the existing projects bridging existing Services >> Grids and Desktop Grids, >> - begin the standardization of the integration of existing Services >> Grids and Desktop Grids. >> >> >> Therefore, we would like to work inside OGF PGI (Open Grid Forum - >> Production Grid Infrastructure) >> http://www.ogf.org/gf/group_info/view.php?group=pgi-wg so that the OGF >> recommendations take into account the bridging of Desktop Grids, in >> particular the issues about Information representation, Security, Job >> submission and Monitoring. >> >> For information about relevant OGF standards, you can look at David >> WALLOM's excellent presentation 'Standardisation: Recent progress >> review and best-practices sharing: Middleware Track', in particular >> pages 27, 28 and 30, at >> http://www.beliefproject.org/events/econcertations/6th- >> econcertation/ppts/eConcert-Standards-Middleware-track.pdf >> >> >> We have to make the best use of, and perhaps improve GLUE2, AUTHZ, >> BES, JSDL, SRM, ... >> >> In particular, the current work of OGF PGI about 'Restricted >> Impersonation' could permit that untrusted computing resources from >> Desktop Grids would have access to storage resources of Service Grids : >> see my presentation at >> http://forge.gridforum.org/sf/go/doc15450?nav=1 >> >> >> Among others, we are inviting following projects for the >> standardization of 'Integrating Service and Desktop Grids' : >> - BOINC (University of Berkeley) >> - LATTICE (University of Maryland) >> - EELA-2 OurGrid (INFN, Italy - Universities, Brazil) >> - CONDOR backfill (University of Wisconsin) >> - Superlink (Technion, Haifa) >> - Clemson Campus Grid (Clemson University) >> >> We have H323 equipment permitting direct video communication, and we >> could use the EVO facility at http://evo.vrvs.org/evoGate/ for video >> conferences. >> >> We are willing to work actively and present our progress at : >> - OGF25 (Catania, Italy) 02-06 March 2009 >> - OGF26 (Chapel Hill, NC, USA) 08-12 June 2009 >> - OGF27 (Bannf, Alberta, Canada) 12-16 October 2009 >> >> >> For more information about EDGeS, you can look at my presentation >> 'EDGeS : Bridging EGEE to BOINC and XtremWeb' at >> http://forge.gridforum.org/sf/go/doc15437?nav=1 >> >> >> Thank you in advance for your comments on 'Restricted Impersonation' >> and for your participation. >> >> >> Best regards. >> >> ---------------------------------- >> Etienne URBAH IN2P3 - LAL >> Bat 200 91898 ORSAY France >> Tel: +33 1 64 46 84 87 >> Mob: +33 6 22 30 53 27 >> Skype: etienne.urbah >> mailto:urbah@lal.in2p3.fr >> ----------------------------------

1 0

Definition of a Production Grid
by Laurence Field 17 Mar '09

17 Mar '09

Dear All, The word Grid means different things to different people and this quite frequently leads to misunderstandings and conflict. This is especially true within OGF where people from many different domains and backgrounds discuss "Grids". While each and every definition themselves are as valid as each other, trying to discuss a concept from two possibly unrelated perspectives is quite difficult. Before we move forward in the PGI activity we therefore need understand what we mean by "Grid" and hence the problem we are trying to solve. It seems that in some recent threads the word "production" has cause some disagreements as this word is more commonly used to reflect quality rather than concepts. From my perspective I can try to define the core properties that I see are key when describing the EGEE infrastructure. I would hope that similar infrastructures with whom EGEE would like to interoperate would have a similar description. I would like to introduce the term "Muti-institutional infrastructures for e-Science" which can be used to describe something with the following properties. 1) Multi-institutional. The EGEE infrastructure is composed by linking resources that reside at autonomous academic institutes. The key concept here is the administrative domain which maps to a real institute and that there is more than one institute in the infrastructure. 2) The Virtual Organization The main aspects that links these institutes is the drive to collaborate in order to do science. The collaborations are defined by Virtual Organizations. 3) x509 Certificates and Proxies Users are identified by x509 certificates which are provided by CAs accredited by the IGTF. Proxies are typically used to interact with services. 4) VOMS To identify which VO a user is belong to is by contacting VOMS. VOMS also supports Roles an Groups within the VO which is implemented by adding attributes to the proxy. 5) Multiple Services The are many different types of services each of which can define their own interfaces which may or many not be a Web Service. 6) Parrallel Information System The information about services is found by querying an information system which is not necessarily related to the service interface. 6) Scale 100s of administrative domains, thousands of users, thousands of services, millions of computing actives and petabytes of data. This may be a can of worms but if we can agree on a set of properties for what we mean by "Production Grid" it might help in the discussions. I don't mean that anything that has different properties is not a production grid, I just want to clarify what this group mean when it talks about a Grid infrastructures. Laurence Laurence

8 18

Re: [Pgi-wg] Discussion about elements/priorities in the field of security
by Duane Merrill 17 Mar '09

17 Mar '09

I would suggest that at some stage we also reference some of the aspects of communication that would be necessary for profiled interop, but that we've been assuming as givens, i.e SOAP over HTTP. Perhaps in (1). Duane On 3/17/09, Morris Riedel <m.riedel(a)fz-juelich.de> wrote: > Hi PGI security folks, > > > currently I see five major elements in terms of security related to PGI: > > > (1) > Authentication/Attribute-based Authorization (i.e. plumbings as named > earlier), maybe first push-based before looking at pull-based models - > although, this of course, can be discussed as well among us. > > > (2) > Agreement on Definition/Semantics/Structure of Attributes > > > (3) > Encoding of delegation restriction/constraints > > > (4) > Interface of delegation service (maybe based on subset of WS-Trust) > > > (5) > Agreement on third party credentials transportation (e.g. a delegated > GridFTP proxy/SAML assertion-based access for data-staging during BES > submissions) > > > As a starting point - have I forgot something in this enumeration? If so - > please answer to this thread. > > > In terms of priorities, I would suggest to focus first on number one, but of > course feel free to comment within this thread. > > > Your co-chair, > Morris > > P.S. I cc'ed the area director of security (David Groep) to ensure that we > did not duplicate efforts done elsewhere (i.e. in the OGSA-AuthZ group). We > have been in touch about a few security issues raised in GIN earlier. CIAO. > > > ------------------------------------------------------------ > 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(a)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) > > >

1 0

Use case: GROMACS
by Oxana Smirnova 17 Mar '09

17 Mar '09

Hi all, sorry for being somewhat late - here's my attempt at a cross-Grid use case. I learned on Thursday that practically every production Grid infrastructure has GROMACS users, so I suppose it is a very good test for our group. And many thanks to Ivan for valuable input. Cheers, Oxana -- -- Dr. Oxana Smirnova Experimental High Energy Physics, Lund University Box 118, SE-221 00 Lund, SWEDEN oxana.smirnova(a)hep.lu.se http://www.hep.lu.se Tel +46-46-2227699 Mobile +46-709-224657 Fax +46-46-2224015

2 2

Discussion about elements/priorities in the field of security
by Morris Riedel 17 Mar '09

17 Mar '09

Hi PGI security folks, currently I see five major elements in terms of security related to PGI: (1) Authentication/Attribute-based Authorization (i.e. plumbings as named earlier), maybe first push-based before looking at pull-based models - although, this of course, can be discussed as well among us. (2) Agreement on Definition/Semantics/Structure of Attributes (3) Encoding of delegation restriction/constraints (4) Interface of delegation service (maybe based on subset of WS-Trust) (5) Agreement on third party credentials transportation (e.g. a delegated GridFTP proxy/SAML assertion-based access for data-staging during BES submissions) As a starting point - have I forgot something in this enumeration? If so - please answer to this thread. In terms of priorities, I would suggest to focus first on number one, but of course feel free to comment within this thread. Your co-chair, Morris P.S. I cc'ed the area director of security (David Groep) to ensure that we did not duplicate efforts done elsewhere (i.e. in the OGSA-AuthZ group). We have been in touch about a few security issues raised in GIN earlier. CIAO. ------------------------------------------------------------ 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(a)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)

1 0

Security Discussions about the PGI Profile on Secure Communication
by Morris Riedel 17 Mar '09

17 Mar '09

Hi PGI team, as stated in the last TelCon on Friday - we agreed to start different E-Mail Threads. Some of you know that I'm slightly personally against e-mail discussions on mailing lists about technical details, basically because... ... "After all is said and done - more is said than done" - thousands of emails - no precise writings/outputs... However, as the group agreed to this approach, I would like to start the discussion here in this thread about the following document: http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/doc man.root.drafts/doc15575 PGI-WG Profile on Secure Communication Strawman version 0.3, March 3, 2009 Duane Merrill, University of Virginia I would like to encourage people to read the document and comment on the mailing list. We will discuss it on Friday, so a good preparation by every participant is crucial. Discussing via E-Mails about it might be good preparation. Your co-chair, Morris P.S. @Steven: Clearly I didn't want to grab EGEE staff for PGI - but Valerio (CC) is an old friend of mine that has a lot of knowledge in the field we are working in terms of security. Of course, its your decision who works in PGI, but he should be aware that we discussing about these things. CIAO. ------------------------------------------------------------ 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(a)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)

1 0

Re: [Pgi-wg] Input for PGI Roadmap Document about Virginia CampusGrid
by David Wallom 17 Mar '09

17 Mar '09

Hello Morris, But you are missing out the unquantified level of funding for the UMD to which gLite/ARC/UNICORE will certainly have access. David On 17/03/2009 09:54, "Morris Riedel" <m.riedel(a)fz-juelich.de> wrote: > Hi Andrew, Duane, > > I know much about DEISA, EGEE, NorduGrid, and more recently also EDGES, > because they have contributed within GIN - but in terms of the > GENESIS-II-based production Campus Grid - I would rather like to have some > background information for the PGI roadmap document: > > (1) > How many users are approximately using the infrastructure daily. > > > (2) > Which codes are running on which platforms, e.g. CFD codes on parallel > machines, or rather docking tools for 'embarassingly parallel' PC pool jobs? > > > (3) > Which kind of resources are interconnected - which kind of HPC/HTC resources > are part of the Virginia Campus Grid infrastructure? > > > (4) > What is the sustainability plan of the Campus Grid in general and GENESIS-II > in particular? > > In Europe the HPC community see an evolution moving from DEISA to PRACE, > while EGEE seem to have an evolution towards an EGI. In both is limited > funding for middleware like UNICORE, gLite. The same is true for ARC that is > not only used in NorduGrid, but also in Baltic-Grid and so on. > > > I think this is also quite valuable information for the whole PGI group. > > Is there a special link to the infrastructure/GENESIS-II Website that act as > the main contact point for it? > > Many thanks for this! > > Furthermore, I would welcome you in the GIN group in order to evaluate your > application requirements for those applications that require resources in > more than one Grid. Many production Grids participate in this group (some > more or less actively/passively) - so it would nice if you join the GIN > community! > > Basically, PGI is a result of collaborations undertaken in GIN (and clear > demands by scientists that would like to use more than one Grid). > > > Your co-chair, > 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(a)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) > > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg

2 1