Hi Jeff,
I don't think it is too strong, but perhaps what might be needed in addition is a summary of the concerns not covered by the 2 documents - i.e. the points raised so far by Kostas and Cristina. If we took Cristina's concerns at face value the service challenges would stop and we would lose the good will of several of the experiments.
Cheers,
Ian
________________________________
From: LHC Computer Grid - Rollout on behalf of Jeff Templon
Sent: Fri 07-Oct-05 19:59
To: [log in to unmask]
Subject: Re: [LCG-ROLLOUT] VO box
Hi,
some comments. also in general i think most of these points are of
course acceptable from a single-site point of view, but do not generally
reflect the agreements in Abingdon.
as i tried to say, sites agree in principle to deploy boxes if / when
they think they are necessary. given sites may have different
thresholds. also i think the security and ops docs are minimal
requirements. there is absolutely nothing to prevent some site from
having stricter requirements.
finally i see that my presentation is not strong enough for most of you
(if some agree, please holler, all i've had so far are comments that it
is too weak). i will work on it but no promises as to when it will be
ready. if anyone wants to try to make it stronger be my guest. i will
do my best in bologna to provide an accurate picture.
JT
cristina vistoli wrote:
> Jeff, Steve et al.,
>
> some input for the LCG VObox Operations Recommendations and
> Questionnaire document and for the GDB presentation.
>
> We think it is important to add the following items to the questionnaire:
>
> 1. Which OS has to be installed in the Vobox?
in one version of some doc it said that the VO did not get to choose
here. it would be the same OS as the WNs at that site unless the site
accepted to do differently.
> 2. the VObox container is middleware. What is the procedure to certify
> it and who
> is supposed to do the certication?
> It should follow to a certain extent the same certification steps as
> the other
> released services.
my 2 cents: this is unrealistic. the reason why we ask for all the info
is that we KNOW it's not certified, hence we make sure it's isolated
from everything else and we know from the outside what is 'normal' and
'abnormal' ... it's the price the VOs must pay for using uncertified
middleware.
>
> 3. Is the software installed in the Vobox 'certified quality'?
> This is important especially if the VObox is not dedicated to a
> single VO.
>
Hmmm, good question although I wonder how you can quantify this.
Which of the current LCG & gLite components would you call "certified
quality"??
> 4: Description of the software installed in the Vobox:
> 4.1 Release notes with list of software components
> 4.2 List of daemons and their purpose
> 4.3 Connectivity requirements
> 4.4 Workflow, explaining the role of the vobox in the grid
> environment, has to be provided
This sounds reasonable to know as it helps a site to judge whether they
believe it's really necessary.
>
> We would like to add the following among the requirements:
>
> 1. Access to the box has to be limited to sgm without interactive login
> and the privileges have to be defined clearly at the VO level; they
> should be
> applied to every VOBOX in the grid. (e.g. it is not acceptable to have
> different privileges or configurations at different sites.)
I don't think this is realistic. I also have the feeling that this
worldwide policy statement is almost as anti-grid as are VO boxes.
>
> 2. Support: The problem investigation will be made by the VO, but the
> Grid managers (local site managers and ROC teams) have to be aware of the
> requirements posed by the installed software.
>
> 3. In a production infrastructure, the configuration of the services
> must be centrally collected
> by the grid managers team, who will distribute it to the regional sites.
> Specifically, the installation/configuration/upgrade of a Vobox MUST NOT
> be a bilateral agreement
> between a site and a VO because in that case is would be too difficult
> to keep track of
> configurations and therefore the service will be very difficult or
> impossible to manage.
The site configures and installs the OS; the VO configures and installs
everything else.
>
>
> As general considerations, we would also like to add the following:
>
> There is a usability concern: if a VO strictly requires a site to have a
> Vobox, that VO
> will only run at a possibly very low fraction of the sites actually
> supporting the VO. This could
> also imply scalability problems.
>
> "Ad Hoc" VO services are not a long term solution, and a burden for site
> and grid administrators. The long term solution should be only based on
> general grid services.
>
> Sites and grid administrators should have the possibility to refuse the
> installation of a VObox if they believe the answers to the questionnaire
> are not
> satisfactory or detailed enough.
>
> Sites and grid administrators have the right to remove a Vobox from the
> network
> in case they believe it is causing security or stability problems.
>
> With contribution from Italian ROC and INFNGrid T1/T2
> Luca dell'Agnello, Luciano Gaido, Davide Salomoni, Cristina Vistoli
>
>
