perfsonar development work

["Jeff W. Boote" <>]

Loukik Kudarimoti wrote:
> These emails are growing too long and I believe we are loosing focus. I 
> will try to summarize
>
> 1) I would argue that the user should not set the CLASSPATH variable. 
> Ant helps us achieve this. We have feedback from users that they do not 
> want to be dealing with CLASSPATH or any other environment variables. It 
> is possible to at least deal with at least CLASSPATH with ant. Is it 
> possible to do so with just perl scripts?
>
> The CLASSPATH that we will set (with or without ant) is for our 
> application only. In my opinion it is a bad idea to say that it should 
> set as a global value which can be shared with other applications (as 
> there are many other java applications). This is not what we are trying 
> to achieve.

There is ALWAYS host specific information needed by an application. The 
questions is simply how the application finds that information. If we ran our 
service from within httpd, we could always setup the mod_env modules to set this.

This part is completely outside of the point of package management. (It is part 
of usability, but needs to be solved no matter how the application is installed.)

This is more about how the application is run and configured. I am specifically 
separating these two points for the rest of this discussion because they do not 
belong together.

Usability:
The fact the LD_LIBRARY_PATH needs to be set at all for the RRD MA indicates a 
problem to me. (man ldconfig - either install the .so in one of the system lib 
directories, or add the installation directory into /etc/ld.so.conf and run 
ldconfig.) We should be installing this for the 'system' not for an individual 
user. Just because developers work as individual users does not mean that is the 
way we should configure the install by default. LD_LIBRARY_PATH is a hack to be 
used during development - not something to use for production services.

Likewise, CLASSPATH should be set in the init.d script that starts the 
application server. For a production service, there should be an init.d script. 
Better yet, install our jar files into the directories that are expected by the 
application server in the first place, making this irrelevant.

> 2) For application download, if apt-get will solve the problem on all 
> platforms, I am ok with it. But the reality is that apt-get works for 
> just a few versions of linux, not all. For Red hat, you have up2date and 
> there is *nothing* for solaris.

Package Management:

Actually, there is pkgadd, pkg-get, AND apt-get for Solaris.

A list of available packages using different package management solutions for 
Solaris:

http://www.sun.drydog.com/packages.php

> But that isn't the main problem. The problem is that our applications 
> are not available for download via such programs. So, clearly the best 
> solution is to download it manually from somewhere by using a URL (i.e. 
> either the original site or a ps-Site). For me, this is not impossible 
> but has some issues that need to be sorted.

Package Management:

Not true. jpackage.org has some of them. Sun has the java rpm directly at:

http://java.sun.com/j2se/1.5.0/jre/install-linux.html

The problem is that there are several URL's and they change. I personally think 
it would be much easier to support something like a yum repository for pS than 
to develop installation/dependency checking/update programs for all of these 
applications.

> The users will have to choose to install the applications automatically 
> into a location where they have enough privileges to install. I don't 
> see any need to make things more complicated than that (i.e. introduce 
> sudo, etc..)

Package Management (configuration of the 'default install'):

Who is our target audience for installing the services?

It is NOC operators.

Lets make it work for them. I personally don't really care if a user can't 
install it very easily without root privileges. This is not an issue for our 
target audience. Developers can set environment variables for non-production 
deployments. That is not our target audience.

> 3) For testing, if the users want to replace the default xml file, they 
> should do so by simply modifying the default xml or by creating a new 
> one and naming it the same as the default xml.
>
> If they don't prefer the above option, then they still have the option 
> to modify the filename in the ant target.
>
> 4) Ant script issues such as "Ant scripts must be used by init.d to 
> start pS on reboot (also requiring some admin level configuration)?"
> init.d will call on a script. The script will be the deploy script that 
> will use ant targets to deploy. The deploy script is part of the 
> original script used while installing. (Good thing that you raised this 
> point. I hadn't quite thought about it)
>
> I hope I have answered all the points. Let me know if not.
>
> I am more convinced than before that perl scripts calling on ant is the 
> best way forward.

Summary:

It probably is the best way for a post-install configuration script to be 
written. It is absolutely NOT the best way to track dependencies and updates of 
packages.

These are two different topics. It confuses the issue to combine them. In my 
opinion both of these statements are true:

1) For long-term viability of pS, it will be necessary for pS services to be 
installable via the normal package management solutions available on each OS. 
This will allow upgrades and dependency checking to happen in ways consistent 
with the expectations of system administrators at NOC's.

2) For pS usability, it is necessary to provide configuration applications to 
help the end-user configure (and test) the installed services.

jeff