ct-grid April 2009

ct-grid@nikhef.nl

7 participants
10 discussions

[Ct-grid] rescheduled grid meetings in June
by Dennis van Dok 23 Apr '09

23 Apr '09

Hi *, because June 1 is a national Holiday, there will be no BiG Grid meeting on that day. That leaves us with only one meeting in June, which is an important month (right before the summer vacation) and which has 5 Mondays in 2009. My proposal therefore is to have *two* grid meetings in June: on the 8th and the 22nd. I'm not sure if this conflicts with other big events or meetings, so please let me know if it does. Regards, Dennis van Dok -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.vl-e.nl Phone +31 20 592 50 12 :: http://www.nikhef.nl/~dennisvd/

1 0

[Ct-grid] Gridforum Bedrijvendag, 13 mei a.s. 'clouds & security'
by Arjen van Rijn 21 Apr '09

21 Apr '09

Beste allen, Graag attendeer ik jullie op de komende Gridforum Bedrijvendag met als thema 'clouds & security'. Het programma is te vinden op: http://www.sun-evenementen.nl/gridforum/ Op deze site kun je je ook aanmelden. Deelname is zoals gebruikelijk gratis voor gridforum-leden (en voor hen wiens organisatie dat vast van plan is te worden). Meer informatie over de Gridforum-activiteiten kun je vinden op: http://gridforum.nl. Groet, Arjen

1 0

[Ct-grid] Cern in South Park
by Tristan Suerink 18 Apr '09

18 Apr '09

Hoi Allemaal, Cern in een aflevering van South Park. http://www.southparkstudios.com/guide/1306/? TS

1 0

[Ct-grid] Next BiG Grid Meeting: Monday 20 April 2009 13.30h in room N3.28
by Dennis van Dok 17 Apr '09

17 Apr '09

The Next BiG Grid meeting will be held on Monday 20 April 2009, from 13.30-14.30h in room *N3.28*. Please take note that this is a different room than usual. Agenda: - Operations summary (10min) - Middleware - Applications - AOB Videoconf is available as usual. Minutes will be taken by Tristan. Enjoy the weekend, Dennis van Dok

1 1

Re: [Ct-grid] Ganga 5.1.9 released
by Hurng-Chun Lee 08 Apr '09

08 Apr '09

Hi Martijn, I don't have any problem to start it ... can you restart Ganga again and see if there are error messages starting Ganga? Hurng On Apr 8, 2009, at 3:41 PM, Martijn Gosselink wrote: > Hi, > > Could it be that there the Atlas specific Ganga modules are not > installed at > Nikhef? Or am I using outdated methods? I get the errors below... > > To setup ganga, I'm using: > > $. /project/atlas/nikhef/ganga/etc/setup.sh > > > Cheers > - Martijn > > > In [3]:config.Athena.CMTHOME='/user/gossie/cmthome/14.2.20' > > --------------------------------------------------------------------------- > exceptions.AttributeError Traceback (most > recent call last) > > /project/atlas/Users/gossie/14.2.20/PhysicsAnalysis/AnalysisCommon/ > AMA/AMAAthena/cmt/<console> > > AttributeError: MainConfigProxy instance has no attribute 'Athena' > > In [4]:j=Job() > > In [5]:j.application = Athena() > > --------------------------------------------------------------------------- > exceptions.NameError Traceback (most > recent call last) > > /data/atlas2/users/gossie/mcnet/14.2.20.1/WjetsAnalysis/cmt/<console> > > NameError: name 'Athena' is not defined > >

1 0

[Ct-grid] mark your calendars
by Jeff Templon 08 Apr '09

08 Apr '09

Yo ATLAS plans for STEP'09 : first two weeks of June. JT http://indico.cern.ch/getFile.py/access?contribId=5&sessionId=3&resId=0&mat…

1 0

[Ct-grid] Fwd: [gridway-user] Fwd: [Globus] Help shape Globus' future: A call for use cases
by Jeff Templon 07 Apr '09

07 Apr '09

Hadn't seen this one before ... Begin forwarded message: > From: "Ruben S. Montero" <rubensm(a)dacya.ucm.es> > Date: 7 April 2009 16:12:14 GMT+02:00 > To: gridway-user(a)globus.org > Subject: [gridway-user] Fwd: [Globus] Help shape Globus' future: A > call for use cases > > Just in case you missed this one... and do not forget to send > your GridWay use case description, needs, wish list... ! > > > Cheers > > Ruben > > ---------- Forwarded message ---------- > From: Ian Foster <foster(a)anl.gov> > Date: Tue, Mar 31, 2009 at 8:05 AM > Subject: [Globus] Help shape Globus' future: A call for use cases > To: announce(a)globus.org > Cc: Raj Kettimuthu <kettimut(a)mcs.anl.gov>, cdigs-team(a)mcs.anl.gov > > > Summary > Over the past few months, within the context of the NSF Community > Driven Improvement of Globus Software (CDIGS: www.cdigs.org) project, > we have begun re-evaluating how we should invest toward Globus' > future. We believe we are starting to understand alternatives and > trade-offs. Of course, our understanding of the needs of the Globus > community is imperfect, and we do not want to make decisions without > broader consultation. Thus, we would now like to engage with the > Globus community to help us work through this evaluation. > A key concern at this point in the process is that we may not have a > complete enough set of uses cases that represent what people are doing > with Globus, or hope to do with Globus. Thus, we ask that you help us > by providing a description of how you use (or hope to use) Globus, > along with contact information so that we can follow up with you to > clarify details and/or participate in subsequent stages of this > effort. We provide below more details on what we are looking for. > Now the longer version... > > Where are we? > We have had tremendous successes with Globus over the past 13 years, > along with some trying times. A challenging issue over the years has > been adapting to the changing technology landscape. Globus Toolkit > version 4 (GT4) was introduced approximately 5 years ago, and much has > changed since then. So what are the circumstances that factor into > our decisions on how to evolve? > > Users: Many healthy, active, growing communities are relying on Globus > for their day-to-day work, including TeraGrid, OSG, ESG, LIGO, caBIG, > and many others. (Based on our anonymized usage reporting, it is > clear there are also many more Globus users than those we know about.) > These communities challenge us with the constant, healthy tension > between demands for stability and new functionality. There are also > new, large communities that are adopting Globus, such as BIRN and > other biomedical communities, which will continue to press these > sometimes conflicting demands. > > Funding: We are fortunate to have significant NSF CDIGS funding for a > couple more years, which allows us to focus on support and development > of Globus to meet user needs. We also have a rich mix of grants for a > wide range of activities, ranging from computer science research, to > infrastructure deployment and support, to application integration, to > complete application development. However, these efforts are of > course finite in duration, and we must be constantly looking to > develop new programs to carry Globus forward. > > Technology trends: The technology landscape in which we operate > continues to evolve at a dizzying pace, with technologies and > approaches such as Cloud Computing, Software-as-a-Service (SaaS), > OpenID, OpenCL, multi-core, etc. In the meantime, technology trends > that we have embraced in Globus, such as SOA and Web services, > continue to mature, for example with the widespread adoption of > lighter-weight REST approaches. > > Aging foundations: Globus relies heavily on open source components > from other communities. Some component choices, such as OpenSSL, have > stood the test of time. Others have not: in particular, on the Java > web services front (e.g. GT4 Java Core), we find ourselves highly > dependent on libraries such as Apache Axis v1.x and PureTLS, which > most of the rest of the world has moved away from. Thus, not only do > we have to support these technologies entirely on our own, but it > becomes increasingly difficult to support our users and our own newer > activities that (rightly) want to exploit new open source software > libraries and approaches. These aging GT4 Java Core foundations are > also inhibiting our ability to effectively address a variety of issues > (e.g., scalability, REST support) in other Globus components, such as > GRAM4 (aka WS-GRAM), RFT, and MDS4. > > Community: The Globus Alliance (dev.globus.org) community of > developers has made many valuable contributions that have seen wide > adoption, such as MyProxy, GridShib, Gaards, and GridWay. However, > the dev.globus.org community has not helped significantly with the > sustainability of existing components by bringing new developers into > to the community who add features or maintain those components. > > Where do we go from here? > Thanks in particular to our NSF CDIGS funding, we have some time and > resources to address these issues, and we will not abruptly leave our > users out in the cold now or in coming years. One CDIGS mandate is to > continue supporting existing users, which we will clearly do. So > regardless of what decisions are made, we will continue to support our > GT4 users as long as we have demand and funding such as CDIGS to do > so. But CDIGS also has two other mandates: helping new users, and > working to ensure Globus' sustainability. And, of course, we have > many other projects that are contributing to development of new > functionality in Globus, which we can leverage as well. > With all of this in mind, our intent is to evolve Globus based on > three principles: > > Embrace widely adopted and community supported software and standards: > When GT4 Java Core was created over 5 years ago, Apache Axis 1.x was > the right choice, but as discussed above the world has moved on. (You > One might argue whether WSRF was the right choice at the time, but > there is strong support for managing/representing state as a first > class part of the web services model, as evidenced by adoption of WSRF > in large communities such as caBIG, and the popularity of REST > approaches throughout the Web 2.0 community.) We have begun evaluation > and prototyping efforts around the many alternative web services > toolkits now available, with goals of: being as conservative as > possible in our choice of technologies (e.g., looking for toolkits > with robust communities); being as flexible as possible in what > requirements we place on our users (e.g., looking to support multiple > web services toolkits); doing as little "invention" or variance from > the standard technology as possible (so we do not have to ship our own > modified version, and plug cleanly into existing systems); while > preserving core notions that Globus users have found compelling such > as rich security and first class management and representation of > state. > > Maintain backward compatibility as much as possible: We recognize that > protocol incompatibilities have been a recurring headache for our > community in the past. Sometimes these are unavoidable as one > progresses forward -- particularly on the tight budget of a non-profit > development group such as ours. But our decisions will be strongly > influenced by our ability to maintain backward compatibility. For > example, one consideration in evaluating web services toolkits is > whether we can provide WSRF (GT4.0 and/or GT4.2) backward > compatibility while simultaneously allowing evolution to newer SOAP- > and REST-based protocols. > > Address long-term sustainability: As discussed above, one key aspect > of sustainability is moving Globus onto newer open source components > that enjoy wide support from a much broader community than just > Globus. Additionally, we have been considering: options for > simplifying Globus, such as removing little-used features which > present code maintenance, stability, and/or scalability issues (e.g., > GRAM2&4 job rendezvous, GRAM2 stdout/err streaming); reinvesting > resources into GRAM2 since it is still heavily used; ceasing > additional development on some components such as GT4 Java Core, GRAM4 > and RFT (e.g., only providing bug fixes, and working with users to > migrate to other options); and re-implementing components in a more > maintainable fashion (e.g., RFT). These examples are merely options > we are considering -- at this point no firm decisions have been made. > > Of particular concern is how to move forward with GT4 Java Core, and > the GT4 services that are built on it. Some of our thoughts are: > > GT4 Java Core: As discussed above, we are investigating various open > source web services frameworks. There are three primary compatibility > concerns: maintaining optional WSRF protocol compatibility while > allowing for migration to non-WSRF protocols; porting existing code > that uses GT4 Java Core to new frameworks; and adopting approaches > that allows for easier protocol transitions in the future. > > GRAM: A large part of the community is still using GRAM2, and GRAM4 > (aka WS-GRAM) has sustainability issues due to its use of GT4 Java > Core. We are considering re-investing in GRAM2 to solve some known > issues (e.g. scalability). > > RFT: While many people have expressed interest in RFT, we have had > limited success with it for a variety of reasons. RFT also has > sustainability issues due to its use of GT4 Java Core. We are > experimenting with a replacement for RFT which is implemented using a > Software-as-a-Service model, and are now looking for users interested > in trying it out and giving feedback. Please contact Lisa Childers if > you are interested. > > GridFTP: Address some persistent usability concerns, so that GridFTP > can be downloaded and operated "out of the box" with little or no > configuration. > > MDS4: Various communities use MDS for various purposes, including for > a service registry (e.g. caBIG, Teragrid), and for monitoring > services. Many good options for monitoring have emerged in the open > source community in recent years, but there still appears to be a need > for service registries. We are considering focusing our MDS energies > more on the service registry use cases. > > Security: Many communities use Globus for its powerful and flexible > security (GSI). There are already activities underway for integrating > GSI with other technologies such as Shibboleth, SAML, XACML, and group > membership services (e.g. VOMS). However, we also need to understand > the role and potential integration of GSI in the context of emerging > technologies such as OpenID and OAuth. > > RLS: RLS is used by several important Globus communities. We will > implement a number of community-requested features, including a > pluggable back end, improved logging, and more streamlined startup. > > How you can help > We need to hear from our users directly about how you use, or want to > use, Globus. It is only through a clear understanding of these use > cases that we can be confident of our decisions. What we need is a > detailed description of how you use Globus, including: > > what for (e.g., a science gateway, a data replication system for a > science experiment, etc.), > what version, > what components, > what features of those components (e.g., the GRAM2 features you rely > on), > what clients (e.g., jGlobus for GRAM and GridFTP, Condor-G with GRAM2 > or 4, etc.), > what sort of performance or scalability issues you are having or would > like to see, > etc. > > Please email the following people (copied on this email) with your use > cases for the following components of Globus: > > GRAM 2, GRAM 4, C security: Stu Martin > GridFTP, XIO: Raj Kettimuthu > Reliable File Transfer (RFT): Lisa Childers > GT4 Java Core, Java security: Ravi Madduri > Service registries (MDS4): Lee Liming > Replica Location Service (RLS): Ann Chervenak > > Please include appropriate contact information, so that they can > follow up for clarification or more details if necessary. > > Next steps > In the coming months you can expect more communication from us as we > work through this activity. We will likely produce one or more > technical whitepapers that describe our proposed directions, on which > we will be looking for feedback. We will also produce prototypes that > you can try to provide early feedback. We may also try to organize a > workshop in Chicago in the near future so that we can discuss these > directions in person -- please let us know if you would be interested > in attending such a workshop. > Viva Globus! > Thanks in advance for your valuable input. > The Globus Team > > > -- > +---------------------------------------------------------------+ > Dr. Ruben Santiago Montero > Associate Professor > Distributed System Architecture Group (http://dsa-research.org) > > URL: http://dsa-research.org/doku.php?id=people:ruben > Weblog: http://blog.dsa-research.org/?author=7 > > GridWay, http://www.gridway.org > OpenNEbula, http://www.opennebula.org > +---------------------------------------------------------------+

1 0

[Ct-grid] Fiber, anyone?
by Dennis van Dok 06 Apr '09

06 Apr '09

For all you techno-geeks out there... This has to be the longest optical cable I've ever seen. This is the inside of a specialized cable-laying ship from Japan, where they are loading a cable to be laid from Guam to Madang. The on-line video linked from the gallery is especially worthwhile because it shows how labour-intensive the loading of the cable really is. http://www.pipeinternational.com/index.php?option=com_myblog&show=Cable-Loa… Dennis -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.vl-e.nl Phone +31 20 592 50 12 :: http://www.nikhef.nl/~dennisvd/

1 0

[Ct-grid] Reminder: Grid meeting on Monday (April 6) at 13.30 in Nikhef H331
by David Groep 03 Apr '09

03 Apr '09

Dear all, This Monday, being the 1st Monday of the month, it's time for another BiG Grid meeting. Start 13.30 CEST Where Nikhef, room H3.31 H323 mcu.surfnet.nl, conference # 1111 Phone +31 20 716 5293, choose "6", then 1111 This meeting will have an update from Jeff on the highlights from the CHEP2009 conference (CHEP=Computing in High Energy Physics) See you on Monday! David "no, I'm not Dennis, just a proxy" G. -- David Groep ** Nikhef, Dutch National Institute for Sub-atomic Physics,PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

1 0

[Ct-grid] Third Provenance Challenge
by Ammar Benabdelkader 03 Apr '09

03 Apr '09

Hi all, Third Provenance challenge is to be held on June 10-11 in Amsterdam. The challenge is mainly aimed for data provenance DEVELOPERS. PC3 is sponsored by VL-e, http://twiki.ipaw.info/bin/view/Challenge/ThirdProvenanceChallenge Participating Teams: http://twiki.ipaw.info/bin/view/Challenge/ParticipatingTeams3 Regards, Ammar,

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

ct-grid April 2009