perfsonar development work

[Loukik Kudarimoti <>]

Hi,

We now have progress :) So, a final summary to make things clear and see 
what to do next

*** Result of discussions ***

I made a list of 4 interactions between the user and installation script 
in one of my previous emails

1) ./perfsonar pre-install

Result of discussion: No consensus reached yet. Discussions to continue
* Jeff prefers not to deal with it. End users should install it using 
apt-get like package management solutions
* My argument is that (based on some of the feedback received, see quote 
from Chris and others below), we need to focus on automatic installation 
scripts of some sort which can install all the dependencies.

2) ./perfsonar configure (all the configuration aspects such as creating 
log4j, service.properties, catalina.properties, components.properties. 
Also, copying xml config file into xml database. In special cases such 
as RRD, it should even tell the user what the value of any env. 
variables should be)

Result of discussion: All agree that we will use perl scripts which in 
turn call on ant targets

3) ./perfsonar deploy (copies all the jars over and deploys the service, 
asks the user to restart tomcat)

Result of discussion: All agree that we will use perl scripts which in 
turn call on ant targets

4) ./perfsonar test (provides numerous test possibilities)

Result of discussion: All agree that we will use perl scripts which in 
turn call on ant targets


*** Next steps ***
I will put 2,3 and 4 in bugzilla and we can try to achieve them for next 
release of pS (should not be too demanding)

What to do about
a) My suggestions on automatic download and install of dependent packages
b) Jeff's suggestions on making our code available via the package 
management route


Quote from Chris

> Unless there is a really simple way of installing perfSONAR, you're
> not going to get this tool widely used.
> And by simple, i mean _really_ simple, like a debian package that can
> be installed via apt-get install, or something like make / make install,
> or just a script that does ALL the installation tasks for you.
> The point here is that I want to be able to just execute ONE programm
> that does the installation for me. No worries about which paths to use
> for the different tools, version numbers of programs, setting environment
> variables, configuring port numbers to use, and so on. 
> There are way to many steps involved in the installation process that can
> go wrong.


Quote from Warren:

> Precisely. Thanks Chris for articulating it so well.


Remembering an informal requirement specification from Eric:

"From our experience in getting our tools installed, campus 
administrators ask for the software to be installed as a single click. 
It is best if the software is distributed in a cd-rom that they can 
simply pop into their machine and don't have to do anything at all"

GEANT2 NOC expectations (based on the experience we have gained when 
talking to them):

* If the software that I install requires root access (for example, 
installing java or installing perl). We prefer to install it by ourselves.
* If the software that is required to be installed doesn't need root 
access to run, its probably easier if it can be done via single click or 
via simple and all inclusive installation mechanism. They won't run such 
applications as root but rather as a user with controlled privileges.

Regards,
Loukik.


Jeff W. Boote wrote:
> Loukik Kudarimoti wrote:
> > Hi Jeff,
> >
> > <snip>
> >
> > > > 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.
> >
> > So, we agree that perl scripts calling on ant targets is the best way 
> > for post-install configuration. I haven't heard anybody else 
> > disagreeing. So, if you can acknowledge this point, I will add a 
> > feature request in bugzilla for this and we drop in from our future 
> > discussions.
>
> Yes - I agree.
>
> > > 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.
> >
> > This is fine for me. It is just one more way of downloading and 
> > installing perfSONAR.
> >
> > A tar ball will still have to be made available on our webpage. So, I 
> > would like to focus on the installation of that particular tar ball 
> > (and all the dependent software) - I will start a new email thread 
> > for that if needed.
>
> I agree with everything except the parenthetical: "(and all the 
> dependent software)".
>
> That is specifically the part we should stay away from.
>
> > > 2) For pS usability, it is necessary to provide configuration 
> > > applications to help the end-user configure (and test) the installed 
> > > services.
> >
> > Absolutely. I believe for configuration and testing, as I mentioned 
> > above, we both agree that perl calling on ant targets is the best way 
> > forward.
>
> Yes.
>
> It appears we have much to agree upon. Perhaps we can concentrate the 
> work there first and worry about the rest if needed later?
>
> To make our code available via the package management route, we will 
> need to ensure the prerequisites are available that way as well. If 
> that works well, our area of disagreement may become irrelevant.
>
> jeff