perfsonar development work

["Jeff W. Boote" <>]

Not surprisingly since we have similar issues... I agree with Jochen  
for how the pS-PS services should integrate into this kind of activity.

jeff

On May 19, 2008, at 6:16 AM, Jochen Reinwand wrote:

> Hi Gijs,
>
> The ideas you outlined seem to be very reasonable for me and should  
> really
> help the developers and also users of perfSONAR!
>
> But I'm not sure how to integrate our Perl services in this  
> approach. Some
> thoughts:
>
> - We are not using maven and it is most likely not useful for us.
> - We use the standard Perl way to create (CPAN style) packages, but  
> use some
> special tricks, to make things easy for us.
> - We have our own repository for our code, that is driven by  
> different needs,
> then the Java repository.
>
> My idea here would be: It is fairly easy to create CPAN style  
> tarballs from
> our repository. These tarballs can normally be used in every Perl  
> friendly
> operating system to create native packages very easily. Setting up an
> automated process for this should be possible. What do you think?
>
> greetings,
> Jochen
>
> On Friday 09 May 2008 15:03, Gijs Molenaar wrote:
> > Hello,
> >
> > I was asked to help on the release team for the perfsonar bundle 3.1.
> > below are some points written down that I want to do, but maybe  
> > some of
> > you have some suggestions about a thing or two. Nothing in here is
> > definitive yet, this is the first draft of the thoughts in my mind  
> > about
> > perfSONAR packages.
> >
> > I want to streamline the package creation of the microreleases, and
> > build a package distribution architecture based upon repositories. I
> > want to create deb/rpm build scripts for every service and put it  
> > in the
> > source, so packages can be created from source directly with one or 2
> > commands.
> >
> > Advantage is:
> > - more flexible package creation
> > - One time work, if there are no big changes in the micro release no
> >   adjustments have to be done to the package files
> > - package creation time improvement
> > - If everything automates well, the whole perfSONAR project can be
> >   compiled and packaged with one command (but maybe that is to
> >   ambitious).
> >
> > These packages will be put in a repository from where they can be
> > installed automatically or manually, what the user wants.
> >
> > I want to create two repositories for RPM and deb based distro's:
> > - One for testing. This way testers can install new packages with one
> >   command and give feedback faster.
> > - One for every stable release. advantages:
> >   - now when there is a 3.0 bundle release, there is no much space  
> > for
> >     error. With the stable repository small fixes can be done after  
> > the
> >     release
> >   - now there is no mechanism for security updates (not that  
> > perfSONAR
> >     worries about that now)
> >
> > using repositories makes life so much easier. you only need to add  
> > the
> > repository one time to your apt/yum configuration, and installing and
> > updating is very easy.
> >
> > Ideally we only need to create 1 RPM for all RPM based distro's, but
> > this needs to be investigated (for example different tomcat versions
> > with different paths are possible).
> >
> >
> > For every service I need:
> > - Short name (for file names)
> > - Long Name / Short description
> > - Long description  (package description)
> > - A building STABLE branch source with building instructions, I  
> > prefer
> >  maven.
> > - Special (build) dependencies (again, I prefer maven)
> > - Contact information (for questions and testing)
> > - Where everything should be installed, why, and read-write  
> > permissions
> >  on file system. default will be _no_ write permissions on  
> > filesystem.
> > - A quick way of testing if the service is working properly
> >
> >
> > I need:
> > - SSH/FTP access to a perfSONAR ftp/http server for package  
> > publication
> > - People helping me to test packages
> >
> >
> > My intention is:
> > - Investigate popular GNU/Linux distributions:
> >  - Red Hat Enterprise
> >  - CentOS
> >  - Fedora
> >  - OpenSUSE (?)
> >  - Ubuntu
> >  - Debian
> >  For latest release and latest release - 1. I don't want to make this
> >  list to big, because all distro's have small differences which makes
> >  the packages too complicated. It would be fantastic to support
> >  FreeBSD, Mac OS X, Solaris, BeOS and UNIX System V, but I really  
> > think
> >  we need to minimise the packaging support for now to get this
> >  streamlined. People can always use the source if they really don't
> >  want to use a supported distro.
> >
> > - Design structure to use the tomcat of the distribution
> > - For tomcat services create RPM / DEB build files
> >  architecture all/any, i386 and x86_64?
> > - Standardisation of installation of non java package
> > - goal is minimal installation effort, so no adjusting  
> > LD_LIBRARY_PATH
> >  or JAVA_HOME
> > - Create yum/apt repositories:
> >  - For every bundle release
> >  - unstable for package testing
> > - Making the tomcat services as secure as possible (tomcat security
> >  manager)
> > - Write basic package build instructions
> > - optional: Write basic install instructions
> >
> >
> > So work flow for 3.1 will be:
> > - Micro release of service is done (in a branch)
> > - I'll create deb/rpm build scripts
> > - optional: create security profile for tomcat security manager.
> > - I'll build packages for service and do small test
> > - Package is uploaded to testing repositories
> > - Developers of service will test the package
> > - feedback goes back to me
> > - New package to testing repositories
> > - Cycle repeats until ready
> > - If all micro release packages are ready a stable repository is  
> > created
> >
> > Work flow of future will be:
> > - Micro release of service is done (in a branch)
> > - Developer will build package with deb/rpm build scripts, or this  
> > can
> >  be done centrally by releae team.
> > - Test the package
> > - package is given to release team, checks if everything is okay.
> > - package is uploaded to repository
> >
> >
> > Implications for the end users are only positive, they will have the
> > option to add a yum/apt repository and install all services with  
> > simple
> > apt-get/yum commands. Direct installation of the packages is also
> > possible (download rpm/deb manually).
> >
> > phew, now I'm going to drink a coffee.
>
> --
> Jochen Reinwand, DFN-Labor
> Friedrich-Alexander-Universität Erlangen-Nürnberg
> Regionales RechenZentrum Erlangen (RRZE)
> Martensstraße 1, 91058 Erlangen, Germany
> Tel. +49 9131 85-28689, -28800, Fax +49 9131 302941
>
> www.win-labor.dfn.de