Burke, S (Stephen) wrote:
> Having an SE at all is optional! However, if particular experiments that
> sites are committed to supporting decide they want a particular service
> it may become less optional for that site.
>
>
>>bbftp is also not a mandatory protocol.  And it is not in the default
>>installation.  And surprise, surprise, hardly any sites advertise it!
>>So I assume hardly any sites have installed it as part of
>>their grid site.
>
>
> i.e. it's in much the same position as rfio. But some experiments do use
> it, and might start requesting that sites install it at some point in
> the future.
>
>
>>If a new piece of datamanagement software came out, that was
>>critical to
>>the operation of the grid, but required sites to install
>>bbftp, I think
>>serious questions would be asked about why this was so!
>
>
> I take it you don't think that CMS sites should have to support phedex?
> (Not that it uses bbftp AFAIK, but it's a CMS-proprietary system which
> sites may well be asked to support.)

I think this is now mixing up the LCG middleware layer with the
experiment specific software.  These are different issues.

If CMS wishes to deploy software that cannot be installed using the
existing Experiment-Software-Manager method, then CMS will have a
problem getting widespread deployment.  This is a genuine concern and
CMS might be thrown back to the old situation of having to
negotiate/work with individuals on a site-by-site basis...  I do not
know how CMS plan to handle this.

I'm not sure what a "CMS site" is.  If you mean sites that agree to
support the CMS VO, they have only agreed to host the software that CMS
can deploy via the ESM method (and allow CMS members to run their
jobs/publish their data, of course! :-) )

I suppose an experiment might try to deploy something like eg. bbftp,
using the ESM's but I do not think this kind of service is what it was
designed for and they would probably find an awful lot of firewalls in
their way...

>>If you were to ask the question: what is the minimal amount
>>of software
>>necessary to install on a WN to be a functioning LCG site (and at the
>>moment, the SFT seems the only judge of that) would that include rfio
>>client software?
>
>
> LCG doesn't require *any* client software to be installed on a WN for it
> to be able to function as a grid site at some level.

?????????????????????????????????????????????????????????????????????????

LCG doesn't require any client software to be installed on a WN?  Can I
assume you are being ironic?? :-)

Those people who have spent the last year trying to get LCG software to
run on Fedora WN, it would be very surprising to be told that LCG does
not actually require any software on the WN...  I strongly doubt any
site would be passed for acceptance in LCG at *any* level without LCG
software on their WNs.

(This is aside from the lcgpbs jobmanager needed gsiftp client software
on the WN to function at all - but of course the lcgpbs is only optional
;-) )

The required
> clients in practice depend on what the applications want to do.

Hardly.

Without edg-rm client software on the WN all the current datamanagement
SFT tests would fail, the site would have GGUS tickets raised against it
and if it failed to install working client software after several emails
from the CIC-on-duty things would start being escalated to the ROC level.

In practice sites install the easiest thing possible to pass the
gstat/SFTs. (ie. not get emails from the CIC-on-duty! :-) )

However the SFT's evolved, they are now the de facto definition of what
constitutes a 'functional' LCG site.  This is not a bad thing!  Defining
an operational system in terms of the tests it needs to pass can
actually be seen as good practice!

If a
> site wants to support a particular application it will have to install
> the clients that application wants - or allow the application to install
> it themselves. (I believe there is now a mechanism for middleware to be
> installed as VO software for the dteam VO.) The SFT are just a tool, VOs
> can and do continue to use sites which fail them if the test is not
> critical for them. Conversely, if VOs start needing something new it's
> likely that tests will be added.

The baseline that LCG delivers to the VO's are sites that pass the SFT.
  The ESM method then allows the experiments to install additional
software - however, this software is, AFAIK, entirely the job software
that runs locally.  Any service connectivity should be via the grid
middleware that LCG has supplied and verified using the SFT.  If a VO
wished to install some service with additional inbound/outbound
connectivity requirements, they would find all sorts of problems.

The LCG middleware on the WN does this, as it requires outbound
connectivity (despite the long history we both know of about *that*
requirement! :-) ).  Being able to install and update this on the WN
using the Dteam ESM is a welcome development, but only (and AFAIK LCG
deployment fully accept this) as long as it requires no configurational
changes (i.e. no new services!)

Of course a VO may negotiate with individual sites to install particular
additional software (although this goes against much of the benefits of
the grid) and may choose to use sites that LCG does not pass on the SFT
(although at their own risk).

And the SFT will evolve as the definition of a functional site changes.
  But the addition of a new service is a major change (as the
introductions of RGMA and SRM SEs are proving!) and the introduction of
datamanagement software that depends upon rfio being present is just
such a major change.  If this is being planned, we should be asking
questions about it, now.

cheers,
Owen.
ps. Have we gone a bit off-topic for TB-SUPPORT????
--
=======================================================
Dr O J E Maroney # London Tier 2 Technical Co-ordinator

Tel. (+44)20 759 47802

Imperial College London
High Energy Physics Department
The Blackett Laboratory
Prince Consort Road, London, SW7 2BW
====================================