perfsonar development work

["Jeff W. Boote" <>]

Loukik Kudarimoti wrote:
> Hi,
>
> The problem to solve is automatic installation of perfSONAR dependencies 
> such as tomcat, axis, exist and ant.We have suggested that users do it 
> manually by existing solutions such as apt-get. We have received at 
> least 3 feedbacks (Chris, Warren and Rafael) that it hasn't worked.

First, that is only part of the problem. Once they are installed, you need to 
maintain them with version control as new versions of things come out.

Where in the wiki do we suggest apt-get? From my reading of the wiki it looks 
like we point them to individual downloads via URL. That is manual. apt-get and 
yum/up2date is not manual. These solutions track dependencies not only of 
packages, but of versions of those packages.

> What I am suggesting is not a 'OR' solution i.e. if users want to 
> install dependencies via package management solutions, that is fine. We 
> call this as manual installation. What I am suggesting is that we also 
> provide the option of automatic installation where we download it and 
> install it for the user.

To do that correctly, you are basically re-inventing package management. 
Granted, with a limited number of packages and a limited number of target OS 
platforms you might be able to do this. But, it does not scale very far in 
either of those directions before it becomes a very difficult problem. (That is 
why these general package management solutions exist.)

> I agree with you that we shouldn't waste our efforts in developing 
> package management solutions. Roman created targets in Ant more than 6 
> months ago and it has been used for RRD MA snapshots and also SNMP and 
> NMS MP snapshots. In fact these targets are available in the common part 
> of ant targets and hence can be used by any service snapshot. These Ant 
> targets, I believe, were quite simple to write up and since they are 
> already there, we should make use of them.

So do you agree or not? You say we shouldn't waste or efforts developing the 
solutions, and then talk about using these simple ant targets.

Yes - the ant targets are simple for the limited number of dependencies they 
currently track. But, they are not sufficient to the task at hand:

- You can not use them to install java.
- You can not use them to install ant.
- They do not cooperate with the other package management solutions used on the 
system.
- They do not track version compatibility.

These are the types of dependencies we are talking about. Warren did not even 
get java installed. His expectation was that he could use the normal up2date on 
his system to get the prerequisites. Seems reasonable to me.

Ask your NOC how would they most likely expect to install the prerequisites. Ask 
how they expect to install most packages.

> The main concern for me is that package management solutions are OS 
> dependent (i.e. different ones for different OSs) and some OS types 
> (such as windows) do not have any package management solutions.

Yes - many of them are OS dependent. Many of the things that need to be 
configured to install something on a given system are system dependent. (I'll 
worry about windows when that is one of our target platforms. But, there is 
windows-update and Cygwin used RPM last I checked.)

> So, its 
> not a good solution to make use of package management solutions inside 
> our installation scripts.

Actually, we should not even have installation scripts. Some post-installation 
configuration scripts are reasonable. But, we should use the package management 
solutions that are out there. And, if the configuration scripts are 
post-installation it is easy to use tools like ant because we will know they are 
already installed.

Roman's scripts do make it much easier to collect the 'jar' dependencies. I 
think they are pretty good at that. I don't think this is a complete solution.

First, it is not even possible for Roman's 'ant' scripts to install all the 
dependencies needed. (java and ant are prerequisites for his scripts)

Second, if you think about future versions of pS things get more complex. 
Currently I don't believe Roman has version management in place. Dependencies 
will get much more complex over time - especially if you allow for the fact that 
users may be using other java applications and other tomcat/axis applications.

I think our time would be better served integrating our applications into 
existing package management infrastructures. I believe it would be much more 
difficult to try and support all the additional needed functionality ourself.

I absolutely agree that apt-get/yum etc. don't work for us right now without 
some work. But, I think it is less work to create a yum repo out of the 
java/tomcat rpm's that are already out there than to write and maintain 
download/installation scripts for them.

jeff