perfSONAR User Q&A and Other Discussion

[Roman Lapacz <>]

Jeff W. Boote wrote:
> 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.

Jeff,


you misunderstood my email. I haven't said that we need to create 
another package management tool. All I suggested is to create a separate 
package with all required configured things to run pS service (something 
which would be very (!) simple to use). Such package could be used by 
people who don't know too much about perfSONAR and just want to see how 
it works. The first impression is very important. If it works fine then 
they might decide to install pS service in their NOCs in production 
servers using advanced installation procedure (and installation package 
prepared for this). Even I wouldn't be surprised if some users would 
like to stay with that simple installation. (I remember that one of our 
(pS) requirements was to provide simple services which could be easily 
deployed.)


I like the idea of using existing package management tools. It is 
something which earlier or later we have expected to work on. My only 
concern is the number of them and OS relations (I prefer Gentoo portage :).



Roman


> 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


--

//  PSNC, Poland
//  phone: (+48 61) 858 20 24
//  http://www.man.poznan.pl