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?
 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.

 3. Is the software installed in the Vobox 'certified quality'?
    This is important especially if the VObox is not dedicated to a 
single VO.

 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


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.)

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.
 

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