Re: [Condor-devel] Official Debian package for Condor

[Peter Keller <psilord@xxxxxxxxxxx>]

On Wed, Dec 08, 2010 at 05:27:49PM -0500, Michael Hanke wrote:
> > However, if you are itching to undertake porting stduniv, I can do my
> > best to write up a porting guide for how to, or at least what you should
> > watch out for, perform a port of stduniv to a newer version of glibc.
> 
> That would be very helpful for getting condor integrated in Debian. I know
> that you already support Debian etch and lenny, and will probably
> support squeeze when it is released, but I'm hoping that it is possible
> to ship a fully tested/integrated condor with some future Debian release
> that supports it right from the start.

It is worth getting other viewpoints from other Condor team members
who are closer aligned with packaging Condor on various distros. I
believe some of them are on this list and hopefully they will respond. I
personally am a bit distant from the native packaging issues with respect
to Condor.

> In Debian's release cycle GLIBC transitions are typically done very
> early -- leaving at least a year till the actual stable release comes
> out. Do you see the chance to have a Debian GLIBC version supported by
> Condor before some future Debian stable release happens? Or in other
> words, how do you decide which GLIBC version to support at which point
> in time?

We try very hard to make it so that a known version of glibc works for
more than several revisions of the distro from which it came, or similar
distros. As for when we decide to support a new glibc, it usually happens
when there is enough customer/community push for it or we need a new
"mother" port--a binary port of Condor with stduniv which runs on a
large number of linux distros.

> Maybe you can think of contributions that would facilitate any
> Debian-related porting and integration issue? Would you be, for example,
> interested in build/test reports from Debian (and maybe Ubuntu)
> development machines submitted to the NMI database?

The Condor members of the packaging team could give you a better synopsis
than I at this time. I know that there has been serious and recent work
on improving the native packaging support of Condor for both Redhat
and Debian.

> To give you some background: Over the past year there have been various
> discussions in Debian regarding batch queuing systems. Debian currently
> comes with Torque, SGE and some others, but somewhat lacks the manpower
> to support a large variety reasonably well. We were thinking about
> converging on a smaller subset, or ideally one thing that does
> "everything". With its feature list and history Condor seems to me like
> the ideal candidate. Now I need to evaluate whether integration of Condor
> into Debian is feasible (given limited resources on either end). I also
> need to evaluate whether a fully functional package is possible (with
> checkpointing, etc.) or just a limited subset can be supported. In the
> latter case it could still replace, let's say, SGE, but at the same time
> Debian developers/users might be less likely to migrate their current
> setups and eventually participate in the maintenance of a Debian package
> of Condor.

Condor without stduniv, known as a "clipped port", is usually much easier
to support. Likely it would compile out of the box right now.

While stduniv is very useful and solves a certain class of job problems
very well, it is used (from our reckoning) by about 10% of our entire user
base. It is debatable if this is due to the restrictions stduniv places
on applications that can be used with it or if the average workflow
don't need it. However, what is known is that one will get a *lot*
of utility from a clipped port of Condor.

Releasing a clipped port of Condor right away is much more useful to
the general community than waiting and porting to get a full port.

I can help at length with the actual nitty gritty of porting Condor
to something. However other Condor members will have to help with the
native packaging issues surrounding it.

Thank you.

-pete