perfsonar development work

[maxim <>]

Hi Nicolas,
I cant say for the rest of ps-ps team but my personal concern is 
that it will be hard to come up with universally adopted requirements
for the deployment filesystem pathnames, logging, config, permissions.
Other than that, I will be more than happy to outsource packaging, 
especially for exotic linux distributions which I dont have any reason to
support.
For perl packages I would recommend to build perl self-contained executables
with
all shared libs included for specific architectures.
Cheers,
         Maxim
 

> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On 
> Behalf Of Nicolas Simar
> Sent: Friday, May 16, 2008 7:11 AM
> To: maxim
> Subject: [Fwd: [pS-dev] perfSONAR 3.1 packaging adjustment proposal]
> 
> Hi Maxim,
> 
> could you please have a look at this proposal with an 
> external point of view and mentioning what you would do for 
> perfsonar-ps?
> 
> Could you please do so by next Monday, so that Gijs can go 
> forward. We would appreicate it very much.
> 
> Best regards,
> 
> Nicolas
> 
> -------- Original Message --------
> Subject: [pS-dev] perfSONAR 3.1 packaging adjustment proposal
> Date: Fri, 09 May 2008 15:03:45 +0200
> From: Gijs Molenaar 
> <>
> To: 
> 
>  
> <>,
>    Loukik 
> Kudarimoti 
> <>
> 
> 
> 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.
> 
> --
> Gijs Molenaar
> 
> fingerprint C660 BABA 4B91 4B5C EB60 7739 4385 8ABA 72EE 99CA
> 
> 
> 
> -- 
> Nicolas
> ______________________________________________________________________
> 
> Nicolas Simar
> Network Engineer
> 
> DANTE - www.dante.net
> 
> Tel - BE: +32 (0) 4 366 93 49
> Tel - UK: +44 (0)1223 371 300
> Mobile: +44 (0) 7740 176 883
> 
> City House, 126-130 Hills Road
> Cambridge CB2 1PQ
> UK
> _____________________________________________________________________
> 
> 
>       
>                                       
>