Hi Olivier,
> Case 1: the component exists as an src.rpm
> rpm:source = wget,
> http://svn.oscar.openclustergroup.org/pkgs/downloads/maui-oscar-3.3.1-3.el6.src.rpm
> rpm:build = rpmbuild --rebuild $source
> deb:souce = wget,
> http://svn.oscar.openclustergroup.org/pkgs/downloads/maui-oscar-3.3.1.tar.gz
> deb:source = file://./debian
> deb:build = dpkg-buildpackage
>
> Case2: the component exists as a tarball and contains a spec file
> rpm,deb:source = wget,
> http://svn.oscar.openclustergroup.org/pkgs/downloads/blcr-0.8.5.tar.bz2
> rpm:build = rpmbuild -tb $source
> deb:build = tar xvfj $source; cd vlcr-0.8.5; dpbk-buildpackage
>
> Case3: the component exists as a tarball and has no spec file and need some
> patches
> rpm,deb:source = wget,
> http://svn.oscar.openclustergroup.org/pkgs/downloads/foobar-0.0.0.tar.xz
> rpm:source = file://./rpm/*.patches
> rpm:spec = file://./rpm/foobar.spec
> rpm:build = rpmbuild -bb $spec
> deb:build = dpkg-buildpackage
>
> (bonus less important): And for the build.cfg, I think that all external
> build dependancies can be computed both on rpm and debian:
> rpm: using rpm -q --specfile
> deb: using a magic dh_<helper>
Yes, I like these ideas. I believe that these would resolve many problems of
building packages on both rpm-based and deb-based system.
> 1. Do we really care about managing all the third party packages?
> => Yes for the following reasons:
> - This avoids having problem and issues related to 3rd party packages
> changing, being upgraded or so and breaking our stuffs
> - This is a all in one solution, thus far more easy to maintain, to install
> and to debug
> - Only onve version to deal with. Example: ganglia: if you chose to use v
> 3.1.7, then the opkg scripts won't crash on an unexpected versions. And in
> the code, no need to handle multiple cases so it works everywhere.
> - using our own build package let us make sure that everything works. For
> exmaple, openmpi: if you use the distro package it won't work with torque as
> openmpi in rhel and fedora at least only support all queue managers except
> torque (tm). You can install and start, but torque is unaware of how many
> sub-processes are started and then fail to manage resources.
> => For the cons, of course it's a non null workload, but, IMHO, it's far from
> being a showstopper. external packages often exists as source rpms or deb
> build tree, and the work integrate the package (in unsupported section) is
> only related to creating the build.cfg, the package.cfg and sometimes some
> opkg.
My question is more like asking if we really want to manage the third party
packages but not asking how we want to manage them by ourselves.
Of course, we have very fundamental third party packages to ship in OSCAR and
it is worth to maintain them but I do not think that we want to manage all the
packages by ourselves. I think it would be good enough if the packages are
shipped to the OSCAR with very basic features.
For example, as a resource manager, torque + maui is good enough to run
parallel jobs on the cluster. If people want to have C/R features, they would
import BLCR or any other solutions.
Some people prefer slurm to torque because it has much better management
interface. It seems to me that slurm has worked much better with IB than with
torque.
Some people like to use just nagios rather than ganglia because they do not
care about the fancy GUI but they like more light weight and better
notification interface.
Some please like mvapich / mpich better than openmpi because of the mpi3
implementation.
There are a lot of other clustering third party packages that we do not ship to
OSCAR yet. We can not manage them all.
Instead, I would like to focus on setting up a system that any OSCAR users can
contribute to build the third party packages without any big learning curve.
Once the system is ready, the OSCAR main frame work should be able to handle
the contributed packages without any issues. That is the one that we have to
make more effort on than building the packages by ourselves.
> 2/ Do we want to have the same interface to build the oscar packages
> including its opkgs for both rpm-based and deb-based system?
> => Yes, and IMHO is possible with the above .cfg file upgrade proposition.
Thanks. Great. I like the idea.
> So IMHO, dealing with third party components is not a big deal provided that
> the build process evolves in something like the above.
My answer is the same as the one in the question 1/
> As for blcr, IMHO, I think that this is an important components in the
> future. In fact, reading the torque mailing list, many messages are related
> to blcr.
> For the future, upgrading oscar_wizard with a maintenance mode to remove
> nodes for maintenance or upgrades and/or deploy new packages is the way to go,
OSCAR is not close to the complete solution about this issue. Dealing with this
issue is much more important than building packages.
> but withouth blcr, how can you stop a node with processes running? no way
> without killing them, thus what would be the usefulness of a maintenance mode?
Why do you think the C/R feature is so critical to the OSCAR cluster? We are
not a superman who can deal with all kinds of the sysadmin works on OSCAR.
If necessary, they can manage it. It would be nice if OSCAR can provide a
system that the OSCAR users can easily build the packages and they can share it
with all the OSCAR users though.
> Of course, for the moment, we need to do a release so users stuck with RHEL5
> can upgrade, thus IMHO, for the moment, we should finish building external
> packages (not handeled by oscar-packager) by hand (systemimager and such) and
> once the repo is tested (deployment with success in step8 for core
> components), I think we can validate a release.
I really appreciate your effort and hard work. I believe that the current OSCAR
with the trunk version is much better than before and I would like to see that
OSCAR will continue to evolve with many OSCAR users' participation.
Regards,
--
- DongInn
Begin forwarded message:
> From: olivier.laha...@free.fr
> Subject: Re: oscar-packager: I'm lost: need help.
> Date: March 28, 2013 7:02:58 AM EDT
> To: DongInn Kim <di...@cs.indiana.edu>
>
> DongInn,
>
> I globally agree with what you say, in fact I started this discussion because
> I think that there are redundant things that are source of errors or
> differences between deb and rpm based ditros. I'm working a lot with rpm
> based distro and when I started the port to ubuntu I saw the gap of thuffs
> that aare unsupported, and I'd like to avoid a situation were oscar on rpm or
> oscar on deb are extremely different.
>
> What I had in mind was to extend the <package>.cfg file format so it fits
> both rpm and deb build like this: (this is an idea, not final spec)
> Case 1: the component exists as an src.rpm
> rpm:source = wget,
> http://svn.oscar.openclustergroup.org/pkgs/downloads/maui-oscar-3.3.1-3.el6.src.rpm
> rpm:build = rpmbuild --rebuild $source
> deb:souce = wget,
> http://svn.oscar.openclustergroup.org/pkgs/downloads/maui-oscar-3.3.1.tar.gz
> deb:source = file://./debian
> deb:build = dpkg-buildpackage
>
> Case2: the component exists as a tarball and contains a spec file
> rpm,deb:source = wget,
> http://svn.oscar.openclustergroup.org/pkgs/downloads/blcr-0.8.5.tar.bz2
> rpm:build = rpmbuild -tb $source
> deb:build = tar xvfj $source; cd vlcr-0.8.5; dpbk-buildpackage
>
> Case3: the component exists as a tarball and has no spec file and need some
> patches
> rpm,deb:source = wget,
> http://svn.oscar.openclustergroup.org/pkgs/downloads/foobar-0.0.0.tar.xz
> rpm:source = file://./rpm/*.patches
> rpm:spec = file://./rpm/foobar.spec
> rpm:build = rpmbuild -bb $spec
> deb:build = dpkg-buildpackage
>
> (bonus less important): And for the build.cfg, I think that all external
> build dependancies can be computed both on rpm and debian:
> rpm: using rpm -q --specfile
> deb: using a magic dh_<helper>
>
> Having this done, my answers to the questions would be:
>
> 1. Do we really care about managing all the third party packages?
> => Yes for the following reasons:
> - This avoids having problem and issues related to 3rd party packages
> changing, being upgraded or so and breaking our stuffs
> - This is a all in one solution, thus far more easy to maintain, to install
> and to debug
> - Only onve version to deal with. Example: ganglia: if you chose to use v
> 3.1.7, then the opkg scripts won't crash on an unexpected versions. And in
> the code, no need to handle multiple cases so it works everywhere.
> - using our own build package let us make sure that everything works. For
> exmaple, openmpi: if you use the distro package it won't work with torque as
> openmpi in rhel and fedora at least only support all queue managers except
> torque (tm). You can install and start, but torque is unaware of how many
> sub-processes are started and then fail to manage resources.
> => For the cons, of course it's a non null workload, but, IMHO, it's far from
> being a showstopper. external packages often exists as source rpms or deb
> build tree, and the work integrate the package (in unsupported section) is
> only related to creating the build.cfg, the package.cfg and sometimes some
> opkg.
>
> 2/ Do we want to have the same interface to build the oscar packages
> including its opkgs for both rpm-based and deb-based system?
> => Yes, and IMHO is possible with the above .cfg file upgrade proposition.
>
> 3/ Do we want to have a simple API to build the OSCAR packages so that any
> new OSCAR users can easily provide their packages for others ?
> => Same as 2/
>
> So IMHO, dealing with third party components is not a big deal provided that
> the build process evolves in something like the above.
> As for blcr, IMHO, I think that this is an important components in the
> future. In fact, reading the torque mailing list, many messages are related
> to blcr. For the future, upgrading oscar_wizard with a maintenance mode to
> remove nodes for maintenance or upgrades and/or deploy new packages is the
> way to go, but withouth blcr, how can you stop a node with processes running?
> no way without killing them, thus what would be the usefulness of a
> maintenance mode?
>
> Of course, for the moment, we need to do a release so users stuck with RHEL5
> can upgrade, thus IMHO, for the moment, we should finish building external
> packages (not handeled by oscar-packager) by hand (systemimager and such) and
> once the repo is tested (deployment with success in step8 for core
> components), I think we can validate a release.
>
> What do you think?
>
> PS: You can forward this discussion to the devel mailing list as I think like
> you that it's important.
>
> Best regards,
>
> De: "DongInn Kim" <di...@cs.indiana.edu>
> À: "olivier lahaye1" <olivier.laha...@free.fr>
> Envoyé: Jeudi 28 Mars 2013 05:19:03
> Objet: Re: oscar-packager: I'm lost: need help.
>
> Olivier,
>
> I think that this is an important discussion.
> Let's clarify the issues first.
>
> 1. Do we really care about managing all the third party packages?
> - Yes
> Pros:
> The OSCAR software set is already prepared for the almost
> production level cluster.
> Cons:
> This is a really time-consuming job and this may hinder the
> OSCAR development.
> - No
> Pros:
> Reduces all the non-OSCAR related works
> Cons:
> A user needs to setup the cluster by installing/configuring
> all the necessary packages by himself/herself.
>
> 2. Do we want to have the same interface to build the oscar packages
> including its opkgs for both rpm-based and deb-based system?
> - Yes
> Pros:
> Makes the build process clear
> Cons:
> Need some help for the full understanding of the deb based
> building processes.
> There is no doubt that having the consistent and simple interface for
> building packages is really good but the problem is how.
>
> 3. Do we want to have a simple API to build the OSCAR packages so that any
> new OSCAR users can easily provide their packages for others ?
> - Yes
> The simpler, the better.
>
> So, based on the above issues that I clarified, my answer would be.
> if we have an src.rpm, is a build.cfg + package.cfg sufficient or is a
> Makefile and a rpm directory needed as well (Makefile so debian build doesn't
> fail???)
> oscar-packager should be able to manage both of them ( 1)build.cfg + rpm and
> 2) Makefile ) just in case of any issues in the deb-based building.
> BTW, only build.cfg + rpm would work if there is no need of patching or some
> extra files. (i.e., there is no need of having package.cfg).
>
> And If we have a tarball and a spec file, is the package.cfg containing an
> src.rpm url required?
> We do not need to have the src.rpm url. Only the build.cfg and rpm/*.spec
> would be OK.
>
> - For the moment, I put both tarball and spec file in the download directory,
> and I fear that somedays, the src.rpm loses sync with the tarball or the
> rpm/package.spec in svn.
> I think that this is the reason that we do not really want to deal with the
> third party package by converting to the OSCAR version. If possible, we have
> to just build the provided src.rpm.
> If we manage the third party tarball, we have to continue maintaining it.
>
> What I mean is that once we have decided to go for tarball (works on both
> debian an rhel) or spec (only rhel), do we need all the files.
> I would like to have both (src.rpm and tarball). Only if the third party
> package provider give its src.rpm, we just deal with it. Otherwise, we would
> have to stick with the source files (e.g., tarball and spec file).
>
> If for some reason we decide to go for src.rpm for blcr, then how do we
> support debian? can we lead to a blcr-0.8.4 build for debian from the
> Makefile and a blcr-0.8.5-1 build from the blcr.cfg file?????
> I do not know. Maybe, shall we ask for the debian users' help? Honestly I do
> not really care about managing the blcr package in OSCAR because we have much
> more important things to deal with and I do not think that it is possible to
> manage all kinds of the sysadmin works.
> I would prefer to provide a solution or way to make it easy to build a very
> fundamental OSCAR cluster and then to maintain / configure the cluster rather
> than try to include almost everything in OSCAR.
>
> Regards,
>
> --
> - DongInn
>
> On Mar 27, 2013, at 1:56 PM, olivier.laha...@free.fr wrote:
>
> DongInn,
>
> - I agree with you, but my question was more: if we have an src.rpm, is a
> build.cfg + package.cfg sufficient or is a Makefile and a rpm directory
> needed as well (Makefile so debian build doesn't fail???)
> And If we have a tarball and a spec file, is the package.cfg containing an
> src.rpm url required?
> - For the moment, I put both tarball and spec file in the download directory,
> and I fear that somedays, the src.rpm loses sync with the tarball or the
> rpm/package.spec in svn.
>
> What I mean is that once we have decided to go for tarball (works on both
> debian an rhel) or spec (only rhel), do we need all the files.
>
> If for some reason we decide to go for src.rpm for blcr, then how do we
> support debian? can we lead to a blcr-0.8.4 build for debian from the
> Makefile and a blcr-0.8.5-1 build from the blcr.cfg file?????
>
> I hope you can understand what I mean with my poor english :)
>
> Cheers,
>
> Olivier.
>
> PS: I'm working on build_package to avoid the pollution of the repository
> with tarballs. I've found the bug, and I'm fixing it....Should be available
> soon.
>
>
>
> De: "DongInn Kim" <di...@cs.indiana.edu>
> À: "olivier lahaye1" <olivier.laha...@free.fr>
> Envoyé: Mercredi 27 Mars 2013 18:19:35
> Objet: Re: oscar-packager: I'm lost: need help.
>
> Hi Olivier,
>
> Yes, as you mentioned earlier, we should not manage the 3rd party src rpm but
> I agree that it is much easier and simpler for oscar-packager to build its
> package.
> If there is a chance to conflict between the oscar included package and the
> dirstro package, we should maintain the source tree with its tar ball.
>
> I don't think that any linux distros provide the blcr package by default so,
> having its src rpm to build its package would be good for now.
>
> Even though we mix up some processes (e.g., only 1) or 2) and 3) ), the
> process of building the oscar packages should be consistent via
> oscar-packager.
> Honestly, if the package provider releases its srpm, I prefer to use it as it
> is. Why bother to adjust it to oscar?
>
>
> Regards,
>
> --
> - DongInn
>
> On Mar 27, 2013, at 1:07 PM, olivier.laha...@free.fr wrote:
>
>
> Hi DongInn,
>
> I'm trying to add blcr build as it is required for openmpi and torque (option
> enabled)
>
> I've upgraded blcr to 0.8.5 as 0.8.4 can't build on fedora (fixed by 0.8.5
> which supports newer kernels. release is effective eventhough it is not
> visible on the web site.
>
> My question is the following:
>
> 1/ In pkgsrc/opkg/<package>/trunk/<package>.cfg there is a reference to the
> src.rpm
> 2/ In pkgsrc/opkg/<package>/trunk/Makefile there is a reference to th .tar.gz
> 3/ In pkgsrc/opkg/<package>/trunk/rpm/<package>.spec this is a spec file.
>
> Which one is usefull, which one is useless??????
> either we keep 1/ or we keep 2+3/ ???
>
> I think that method 1 is good for package like blcr where we use the original
> package
> And I think that method 2+3 is usefull when packagin thinkgs laike maui as I
> had to add a patch, thus se do not use the original package...
>
> For the moment, I've immitated other directory (thus there is redundancy),
> but it should build.
>
> (I hope to have a blcr-dkms in the future, but for the moment, we have at
> least a usable blcr).
>
> --
> Olivier LAHAYE
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
Oscar-devel mailing list
Oscar-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oscar-devel
