perfSONAR User Q&A and Other Discussion

["Jeff W. Boote" <>]

Roman Lapacz wrote:
> Sounds OK but I still believe that we need a separate package which 
> contains all prerequisites and required very minimal set of questions 
> (use of default parameters). Something similar to "one click".

There are SEVERAL package management solutions out there. It is absolutely NOT 
reasonable for us to become too involved in the development of these as part of 
the perfSONAR project.

We should be consumers of package management solutions - not developers of them. 
It is actually not that difficult to configure most applications to use 
pre-defined defaults for the installation. (And, there are enough applications 
that need to be installed from each of the package-management solutions out 
there that there are meta-file package description ways of describing your code 
so it can be consumed by several of the package-management solutions.)

Just a partial list of available package-management solutions:
        For Linux there is: apt-get, rpm, yum, up2date
        For FreeBSD there is: Ports
        For MacOS there is: MacPorts, Fink

Every OS out there that is a reasonable 'target' OS for pS has something like 
the ones above available.

Apache httpd itself is installed this way on most operating systems. The httpd 
server typically requires lots of custom configuration - yet this still works 
without asking the user questions. Most people do need to add additional 
configuration to it, but the 'install' and the dependencies is completely 
handled by the package management. And, the nicest thing of all is that UPGRADES 
are handled by the package management solution.

I do not think it is reasonable for us to be dealing with the dependencies 
directly ourselves in ant or perl (or any other language for that matter).

From Warren, I understand that there are difficulties with RHEL 4 and the Java 
applications because RedHat wants to make money. There is a relatively easy 
solution for this. We can take the rpm packages available from jpackage.org and 
provide them from our own yum server. (Perhaps there is a freely available one 
out there - but I have not found it yet.) This would allow users to install all 
our dependencies (and keep them up to date) by simply adding our repository to 
their yum and/or up2date channel set. This is completely consistent with the way 
these users are keeping their other applications up-2-date on those systems. 
(This is how you make things easy for the end user - you keep them consistent 
with what they expect. Creating yet another package-management solution is NOT 
what they expect.)

We could of course write our own program to install the dependencies, but then 
what happens when one of those dependencies is upgraded? Or, lets say they 
install another application that needs Java. Our installs would not be in their 
rpm database, and confusion will be very likely.

We should work within the package-management solutions that already exist for 
the given OS. We have enough work to do coding our own applications and services.

In fact, I think our services should be packaged this exact same way. Then the 
user could use yum (on Fedora or RHEL) to install it and have all the 
dependencies handled.

This does NOT negate the need for a configuration application for each of our 
services. But, this is going to be fairly service specific in any case.

For example, the default install of the RRD MA should just install an example 
RRD file and have the service use that data. Then test scripts can be run at the 
end of installation to ensure it works - based on the example set of data. A 
configuration script should also be installed. This would allow the user to 
modify the configuration to have it point at their own RRD files. (Initially, it 
could even be more of a diagnostic tool that queried the system to determine how 
things are currently configured and just advised the user on the specific files 
that would need to be changed if they wanted to change things.)

jeff