Like others have said, it seems highly unlikely that R-GMA
is running daemons on the WNs. In EDG at least it never did.
I can understand Rod's confusion though, as script stuff
has never been a strong point of the R-GMA group ...
the standard example was that it was normal for a certain
startup script to ALWAYS fail (meaning if it didn't fail, you
might start to worry!). Now we can add a bad name to the
list, as there should be nothing to restart on a WN.
J "send in the paratroopers" T
On Mon, 2004-08-09 at 23:11, Steve Traylen wrote:
> On Mon, Aug 09, 2004 at 01:53:15PM -0700 or thereabouts, Rod Walker wrote:
> > Hi,
> > Extra requirements on the WN's are very bad for interoperability, and
> > particularly for making use of shared facilities. Up to now, the LCG
> > requirements can be accomodated by a combination of reasonable requests
> > to sysadmins, and non-root sofware installation in shared areas. In
> > particular, one can install /opt/edg, /opt/lcg /opt/globus
> > /etc/grid-security/certificates in an NFS mounted area and set
> > environments variables. In this way, the LCG data handling tools work
> > transparently on vanilla WN's.
> > As you can appreciate, doing this outside the core LCG development team
> > is a risky business, and one runs the risk of meeting a showstopper -
> > some requirement that cannot be accomodated in a non-intrusive way. My
> > concern is that the RGMA client may be the showstopper.
>
> Hi Rod,
>
> With R-GMA it is possible to install it wherever, one of the configuration
> options to the config script is by default /opt/edg which can be set to whatever.
>
> Why do you think a deamon is needed on a WN, I not believe this to be the case?
>
> I agree with you though, more requirements on the WN is not good as
> I've discussed with you before, expecting R-GMA and EDG-RM to just be there
> does not seem good for bringing other sites together within EGEE..... Unless of
> course you let this software set be = LCG2_2_2 and then sites can join and not publish
> that they support the complete LCG environment by missing this off?
>
> Steve
>
>
> >
> > Could someone familiar with the clients' workings tell me if it is
> > possible to install stuff on a shared area and set environment
> > variables. What is needed from the native linux installation,
> > e.g./usr/local, and could this be replaced by things in $EDG_LOCATION ?
> > Particularly daunting is that this client seems to have daemons running
> > on the WN's. Could these be started at run-time only when an lcg job is
> > on the WN, eg.in the wrapper check for running instances, and then start
> > them. Apart from the fact that shared facility admins will have kittens
> > if I tell them this deamon is needed, it seems like a potential headache
> > to ensure that these deamons are running on all WN's.
> >
> > Cheers,
> > Rod.
> >
> >
> >
> >
> > Markus Schulz wrote:
> >
> > >Dear site administrators,
> > >please take the time to read this mail and respond.
> > >
> > >A new release with several updates addressing known problems has been
> > >prepared.
> > >In addition R-GMA has been added to the release. R-GMA is important for
> > >several experiments
> > >since they want to use it for monitoring their jobs. R-GMA will allow
> > >to get the accounting infrastructure
> > >working.
> > >In addition in this release we suggest, following the request from the
> > >experiments, that larger sites move to a layout
> > >of their queues that will provide an individual queue for each VO.
> > >
> > >The release is fully backward compatible.
> > >
> > >The documentation is as always available from the release page
> > >http://grid-deployment.web.cern.ch/grid-deployment/cgi-bin/
> > >index.cgi?var=releases
> > >
> > >Before you all now jump up and start upgrading it would be good to
> > >first plan this process a bit.
> > >
> > >I suggest to go through the following steps:
> > >-----------------------------------------------------------
> > >
> > >1) New sites that are in the process to join move to LCG-2_2_0 without
> > >going to any other version
> > >
> > >2) CERN will upgrade in the next 2 days their production system
> > >
> > >3) Large sites with more than 100 CPUs (using fuzzy logic I accepts
> > >those with 90+ in this set of large sites):
> > > Those large sites should sent a notice to the list about when they
> > >could do the upgrade.
> > > Depending of the availability we then schedule the upgrade of those
> > >sites. We should not upgrade all at once to avoid negative
> > > effects on the experiments data challenges.
> > >
> > >4) If we have managed successfully to upgrade most of the larger sites
> > >we address the migration of sites in the interval 20-100 nodes.
> > > We expect this to much smoother then, because by then we should
> > >have encountered most of the problems.
> > >
> > >5) After the majority of those sites is at 2_2_0 the remaining smaller
> > >sites follow.
> > >
> > >
> > >The objective is to avoid a rush of all sites to the new release and
> > >all finding the same problems and in turn creating troubles for the
> > >experiments.
> > >
> > >Any suggestion to make this transition as smooth as possible is
> > >welcome. However, do not forget to send a short note on when you could
> > >find the time for the upgrade.
> > >
> > > markus
> > >
> > >p.s.
> > >
> > >I am aware that we have the summer holiday season and all sites are
> > >running with somewhat reduced staff.
> > >
> > >
> > >
> > >************************************************************************
> > >*******
> > >Markus Schulz
> > >CERN IT
> > >
> > >
> >
> > --
> > Rod Walker +1 6042913051
>
> --
> Steve Traylen
> [log in to unmask]
> http://www.gridpp.ac.uk/
|