Installation task meeting held on 18th and 19th January 2001

Present: Massimo, Stefano, Luca, Willem, Ton, David, Thorsten, Philippe.

Excused: Kors

1. Experience and resource.

Were present representatives of INFN, NIKHEF and CERN.

INFN has some experience with ANIS (CERN network installation controller) and
RedHat kickstart. They estimate their participation to the TTask
 to 1 FTE (0.5 + 0.3 + 0.2) for the next year.

NIKHEF has experience with D0 farms and diskless installation mainly. They
could bring around 2 FTEs to have tools to build coherent environment and
system.

CERN has already some tools which covers most part of the Task: AIMS (front end
to kickstart), ANIS, SUE (Configuration) and ASIS (Software distribution) but
they lack integration, central configuration management and scalability. CERN
is ready to participate for 3 FTEs.

2 Task definition.

The iinstallation Task
 is responsible for building the tools which brings an empty or badly
configured computer box connected to our network to the state of being usable
into a target farm. This implies that:

 the right operating system runs on the machine

 the system, network and resources are configured properly

 the necessary applications are accessible.

The supported platforms will have to be defined but presently Linux and Solaris
are our targets.

3. Short term planning.

To start with, the task should make a survey of the existing tools analysing
their strength and weaknesses. This could eventually lead to a recommendation
for a first prototype of system for M9 based on existing software.

In parallel, it is necessary for each centre to proceed to the collection of
requirements and to refine the definition of the domain covered by the ttask..

The target platforms have to be defined and the protability issue taken. Our
installation tools may be based on vendor installation systems which means that
we shall develop them only on our target platforms but the APIs will be public
and easy to adapt to any other vendor by interested parties. The upper layers
of the full installation process will be designed and implemented to be as
portable as possible.

To get a machine adapted to a given farm, it is necessary to get its
configuration and the role of our task is to read this configuration and
transform the environment on the machine to reflect exactly the configuration
received. Therefore, it is necessary for our task to interact closely with the
other task of WP4 called Configuration Management. We need to define with them
the content that we need to put in their data base in such a way they
incorporate it nicely and we

also would like to have agreement with them on the APIs for reading their data
base.

4. Immediate actions.

Creation of a mailing list: hep-proj-grid-fabric-install@listbox.cern.ch

Video Conference: Wednesday 07 Feb 10:00 - 12:00 (???)

Task architects: Kors, Michele and Philippe (coordinator).

Contacts to be taken with University of Edimburg to integarte them in

the task force.

5. First thoughts on a global design.

See graphic.

6. Open questions to/with Configuration Management.

What is the most sensible primary key for the config DB ?

   MAC address, IP, hostname,...

Which private information do we want to store in the config DB ?

   root password, ssh node key,...

Which level of security do we want for the DB query process ?

7. Internal questions.

What is a box ?

   computer, PDA, printer, Cray,....

As we more or less agreed that our tools should also work on desktops, can a
user have the priviledge to install/change software on his desktop ?

Do we consider disconnected operations, for instance for laptops ?