Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.eso.org/projects/dfs/to-do-list/olas-to-do-open.txt Дата изменения: Thu Feb 1 19:18:24 2001 Дата индексирования: Sat Dec 22 23:38:38 2007 Кодировка: Поисковые слова: рер р р р р р р р р р р р р р

================================
* LIST OF OPEN ACTION ITEMS *
================================

Last update: Thu Feb 1 17:18:24 MET 2001

----------------------------------------------------------------------------------------------
ID Chronological number (to be updated manually).
Comp Name of the DFS project or component (SAF, VCSOlac, FrameIngest, DO, RBS,
-pipe, ...). In most of the cases, it's enough to have a To-Do list
per DFS project (e.g. SAF). However, project managers may decide to have a
To-Do list per component, if appropriate.
Origin Meeting name/review/date during which the action item was originated.
Type ACTION= for a normal action item;
BUG= for an item related to a bug report;
CHANGE= for an item related to a change request.
Prior Priority= LOW, HIGH, CRITIC
DueDate Either a specific date (YYYY-MM-DD) or a specific new release (in that case,
corresponding date has to be specified in associated DFS component schedule).
Resp Responsible name; even if several persons can be involved in the action item, one
should be responsible for follow-up.
Status INIT= to be started; SUSPEND= suspended, waiting for external inputs;
PROGRESS= action in progress.
Description
Detailed description. For BUG and CHANGE, specify the SPR number and a short
description: the complete description of the SPR must be found in Action Remedy.

----------------------------------------------------------------------------------------------
ID Comp Origin Type Prior DueDate Resp Status
Description
----------------------------------------------------------------------------------------------

001 OLAS cguirao/2000-12-04 ACTION LOW June 2001 szampier INIT

OLAS and filesystems. RAID systems on DHS machines provide disk capacity to keep raw data
for ~10 days. The RAID was dimensioned 200GB for UT3 and 400GB for UT4, however the largest
filesystem one can configure on HP is 128 GB.
The files delivered to DHS are stored under "/data/raw/".
The problem is: how could DHS make use of a 400GB RAID capacity under /data/raw if the
largest filesystem is only 128GB?
Worklog:
2001-01-15 : informal meeting CG-SZ. An external process (deamon or cron job) could
monitor the usage of the OLAS filesystem and, when the available disk
space is below a given value, move some files (the older ones?) to another
partition, replacing the data files with soft links. The feasibility of this
solution has to be verified, in particular how to be sure that DHS
is not accessing the files while they are moved.


002 frameIngest szampier/Dec 2000 ACTION HIGH ?? szampier INIT

frameIngest and VLTI. Depending on the requirements for the VLTI archive, it may
be needed to modify frameIngest to read fits keywords from a generic extension header.
I see here the possibility of re-engineering frameIngest in order to make it
more flexible: i.e. the keywords to read and store in the database should be
configurable, not hard-coded.
The estimated time required to re-engineer frameIngest is about 2 weeks.
I don't know the deadline for this action item, it may be set to the next (first)
DFS commissioning at VLTI/VINCI.


003 OLAS mperon/Dec 2000 ACTION LOW ?? szampier INIT

OLAS and very high data rate instruments. The new instruments that will be installed
at the VLT in the next years will produce a very high data rate (VHDR). In this context,
an analisys of the performance of OLAS will be carried in order to answer to the
following questions:
- how can we measure te performance of OLAS (which parameters should we
consider ?)
- which is the performance of OLAS ?
- will OLAS be able to deal with the next generation instruments ?
- if not, can we improve the performance of OLAS ? how ?
- is the current OLAS (DFS) architecture suitable for a VHDR instrument ?
- ...


004 cdpacker DFO/Dec 2000 ACTION VERY HIGH 31-01-2001 szampier PROGRESS

The Data Flow Operation Group has requested a tool to support the quality control scientists
in the preparation of service observing packages. The core part of the tool is the one
responsible of applying a set of user-defined rules for classifying/associating the
files and retrieving the list of files/records from the filesystem/archive that constitute
a package. A working prototype of such a tool has already been developed, using the
python scripting language. The idea is to provide to the users an environment that hides
all the unnecessary details (e.g. reading a keyword from a database or from a file, etc.)
where they can write in a simple way the rules needed to classify/associate the data.
Some tests has already been done with DFO members, and the general feedback was positive.
To Do:
- implement a local database structure
- add the capability of applying the rules to a local database
- collect more requirements on the input/output to the tool and
implement them
- add more logging informations
- write documentation
- test


005 dppacker PAR-DHA/Oct 2000 ACTION HIGH ?? szampier INIT

new dppacker. During the last months, requirements has been collected for an
improved version of ddpacker. I'm still not sure about the implementation,
we could take advantage of the work done for the cdpacker but we would need
to re-write dppacker in python and install python at the observatory.
Besides the one mentioned, there are other open issues concerning dppacker,
which can be discussed in a kickoff meeting at the beginning of February 2001.
The estimated time for re-developing dppacker is about 3 weeks.


006 DHS SCCB#1/Feb2001 CHANGE HIGH 01/04/2001 szampier INIT

Prepare a short evaluation plan for Change Request DFS00838 about "DHS handling
several storage areas" (implementation details, expected schedule). Involve Cguirao.


007 DHS SCCB#1/Feb2001 BUG HIGH 15/02/2001 szampier INIT

Check Archive content with Andreas about BUG DFS00813 (DHS: gen archive file name)


008 OLAS SCCB#1/Feb2001 BUG HIGH 15/02/2001 szampier INIT

Check DB content : is BUG DFS00668 ("no DPR TECH keyword in UVES BIAS and DARK frames")
still existing ? If so, coordinate with gmekiffe to ask rhanusch. The same for BUG DFS00666
("UVES BIAS frames have non-zero EXPTIME keyword content).


009 DHS SCCB#1/Feb2001 BUG HIGH 15/02/2001 szampier INIT

Ask Bruno for more details about BUG DFS00662 ("DHS: cfitsio: failed to reallocate memory
(mem_write")) to define the expected Release solved. The same for BUG DFS00661 ("DHS: message
file has the wrong size (too short)")