1. Announcements
- ER4 date fixed
- CNAF data storage/access info page

2. AdV online farm benchmarch (see Stefano's email)

3. /procdata re-organisation
From Didier:

A short information before we discuss at the VDAS meeting. 
Most the current bufferv disks content can be distributed between various activities (BURST, CALIB, DETCHAR, etc...). Current bufferv disk usage (https://wwwcascina.virgo.infn.it/DataAnalysis/buffervx.html) shows the following rough summary: 
BURST :  54% of 5 TB used 
CALIB :  82% of 2 TB used 
CW :  70% of 3 TB used 
DETCHAR :  48% of 4 TB used 
DAQ :  1% of 1 TB used 
FREE :  1% of 3 TB used 
HREC :  53% of 10 TB used 
MBTA :  61% of 5 TB used 
SPECTRO :  83% of 2 TB used

4. Software alignement
- status
- problems: Fr,  Dy
- CVS --> SVN migration readiness

5. AOB

Stefano's emails:

"As you have seen we have online also the second multiprocessor machine recently bought, 
which is identical as hardware and network configuration to olserver40 which is used for MBTA.

We would like to start some tests comparing different baseline OS or virtualization configurations 
to collect information for the next on-line computing farm architecture.
 
To speed the tests it would be very useful if some benchmark suite could be extracted from the Virgo 
applications that could be representative of the jobs that will run at Cascina, much like what was done 
during the evaluation of the current computing farm alternatives.
 
Ideally the benchmark applications should run deterministically depending on a set of configuration 
parameters (resulting in a tunable execution time, number of processes or memory usage, etc.) and 
eventually some fixed input files.
 
If the benchmark applications were self-contained they could be used to test also off-site hardware, but 
for the moment we could limit the tests to Cascina using the common environment.
 
For example the benchmark application could be simply a procedure (command lines ..) to run at wish an 
instance of a current virgo application in a controlled way without harming the status of the normally 
running instances.
 
Note that there will be no network/storage tests for the moment, therefore all the benchmarks should run 
with I/O on the same fixed disk. If there is the need of reading from files they will copied on the local 
disk. Maybe in case of rawdata a single set of, say, 500GB could be selected and fixed for all applications.
 
What do you think ? any suggestions are welcome"

"Basically the areas to be tested are the following:
 - independence of the applications from the virtualization layer (kind of hypervisor, kind of 
virtualization, etc.)
 - coexistence/interference of the applications when running on the same host but inside different 
contexts (for example linux containers)
 - independence of the applications upon kernel changes or OS configuration
 - performances measurement in various hardware setups (memory, number of cores, network I/O, storage I/O)
 
Except for the last item the purpose is mainly to insure that we can work rapidly on the platform layer 
while keeping consistency.
This does not exclude that at some time selected users are called to test a given platform more 
extensively.
 "

Minutes: Loic, Didier, Stefano, Giuseppe, Livio, Elena, Florent, Nicolas, MAB, Frederique

1. Announcements

ER4: Nicolas: 4 or 6 weeks run. Start mid-July with a slow start.
Didier asks for configurations:  
- Hanford central interferometer (DRMI)
- Livingston: one arm?
- Virgo: VSR3 recoloring + DQs as for ER3
Didier wonders about real vetoes based on Env channels for testing data transfer for Virgo?.
--> no real useful application during ER4. Could be done anytime if needed. Nicolas reminds that data are constinuously flowing right now.

2. Online farm benchmark
Stefano: the goal of the work done by Giuseppe & Stefano is to be able to run all applications in a flexible environment. Test some virtualization layers (see Giuseppe presentation of few months ago [ref]). Many configurations and many different software. Want to test middleware and not only hardware. We need to be sure Virgo applications don't depend (or figure out the level of dependance) on these layers.

Many online Virgo applications use shared memory.
Want to be sure OS upgrade is not impacting Virgo applications.
Would prefer a single executable with a single input file. But a single script would be OK. The other point is VCS control.

Example of the content of the benchmark
1 FdIO server reading data on disk (local disk).
- 1 MBTA process doing first step processing (info from Benoit) accessing data from the shared memory
- 1 Omicron process accessing data from the shared memory (need ~10 channels in the shared memory)
- Detector Monitor processes?: no network testbed. Maybe not easily to implement, but to consider later when network will be tested (end of the year)
- NoeMi: use of mysql db. Would require to copy the db locally. Also run with condor. Alberto will investigate how much time it would require to have an independant set of processes. Condor is able to manage virtual machines. Can create virtual machines.
- other computationally stressing applications are invited.
  
Frederique reminds that MBTA run on ER3 as for any olserver machine (standard installation. No virtualization)

Stefano: local disk will be 1 TB big.

Alberto asks about the data access upgrade:
Stefano: this concerns the test of the file server system. After first test phase that mainly focuses on compution stress.
Planning given to project office manager. Tender mid 2014 for storage. Setafno reminds that the benchmark must not impact the current Virgo environment (use of VTF like environment).

--> status of this at the next VDAS call.
 
3. procdata reorganization
Organization by activities/type of data: all agree.

Loic asks for the possibility of quotas.
Livio thinks this is possible with xfs. If not a simple cron job could do the job.

Florent : Web browser access?
Stefano: By default there is no web access. But there were few buffer (v3, v5 and v6) made web browserable by a replica system. Should be possible to provide something similar. Need to know which data set really need web access.

--> MAB will send an email to get input.

4. Alignement software
Pb with root/Fr/Frv: test under way. If this can't be solved, root will become part of the Virgo set of basic packages
Pb Dy/root/v5r34. There seems to be something incompatible. Comes from the display. Didier run Dy without display. No pb

Proposal: adopt root v5r34. Try to keep Dy in the environment but need to be sure root v5r26 is not generating pb (keep it private in Dy).
Didier mentions a major upgrade of Dy for this fall. Will try to solve the current root v5r34 pb with Dy.

CVS-->SVN migration: Franco will present slides next monday in the DA session at the Virgo week. He is currently running scripts comparing the contents of the original CVS archive and the SVN ported one and he has found no major problem (just comparison is made a bit cumbersome because of the change in date format within CVS keywords like "$Date:" and few not supported CVS keywords).
He is now trying to find the best way to check for last historical access to an archived Package via CVS history

5. AOB: next VDAS call in 2 weeks