[Pkg-gridengine-devel] pkg-gridengine first steps

[Mark Hymers]

Hi,

On Tue, 24, Apr, 2007 at 12:03:37AM +0200, Michael Banck spoke thus..
> sorry, I wanted to mail earlier but I was a bit busy over the weekend
> visiting my parents.

Yeah, I wanted to look at this earlier but had a busy weekend too.

> Anyway, I checked in the debian/ directory of my old work on gridengine
> to svn://svn.debian.org/svn/pkg-gridengine/trunk/debian , comment very
> welcome.

Is there any reason we're only keeping the debian/ directory in
subversion?  For freeradius, we keep an upstream branch in
/branches/upstream/trunk and tag upstream releases in
/tags/upstream/freeradius-x.x.x.  We then keep a full tree in
/trunk which is the upstream + the debian directory.  Updating to the
new upstream is easy; we use svn_load_dirs to load it into
upstream/trunk, then svn merge that into /trunk.  Personally, I just
find it easier to work this way but your mileage may vary :-)

> Last night, I managed to get a trivial job executed for the first time.

Excellent!

> There's also debian/TODO which lists the (IMHO) missing stuff, feel free
> to add to it.

One of the important ones of these (for me) before upload would be to
offer four packages instead of the current two.  I'd divide it up like
so:
 * gridengine-master (the master / scheduling daemons)
 * gridengine-exec   (the execution daemon)
 * gridengine-client (the client utilities)
 * gridengine-common (anything which is needed by >1 of these)

I'd have to check (off-hand I don't remember) how much the execd needs
to run.  The reason for this division is that in most cases you will
have machines configured with just the execution daemons and probably
don't want the scheduler daemons even installed there.  Thoughts?
If this is ok, I'll give doing it a shot.

> Probably the most pressing right now is figuring out how to run the
> client programs without having to set environment variables (their
> startup expects SGE_ROOT SGE_QMASTER_PORT and SGE_EXECD_PORT to be set).
> Maybe we can hardcode the first one to /var/lib/gridengine (if $SGE_ROOT
> is set, it would take precedence, of course), and get the other two from
> /etc/services (there's support for this already).  We just need to get
> some ports (which?) allocated here.  I've never had to bother with this
> in Debian myself, anybody know where to request this?
>
> The daemons aren't a problem, they could just source
> /etc/default/gridengine in their init scripts (to be written) or so.

Hmm.  My /etc/services has:

sge_qmaster 6444/tcp            # Grid Engine Qmaster Service
sge_qmaster 6444/udp            # Grid Engine Qmaster Service
sge_execd   6445/tcp            # Grid Engine Execution Service
sge_execd   6445/udp            # Grid Engine Execution Service

in already.  It appears to have been added in netbase 4.28.  So we
should be good to go for the SGE_*_PORT stuff.

The problem is that (by my reading of policy) we can't require
environment variables to run at all.  So for SGE_ROOT (and presumably
SGE_CELL), we need to hardcode some defaults.  We could of course simply
wrap all of the executables as scripts which, if SGE_ROOT and SGE_CELL
aren't set, source them from /etc/default/gridengine.  That should be
easy enough to sort out and is (sort-of) suggested in policy 9.9.

> Long-term (Lenny release) it might be nice to have debconf configuration
> (I don't really know debconf either, I admit), but short-term some
> reasonably sane default configuration should be doable, at least for the
> time being with gridengine in unstable.

Agreed.  Debconf is a "nice to have" but not "necessary" for the
initial upload IMO.

> Using sgeadmin as admin user seems reasonable to me, just getting a
> dynamically allocated system uid/gid seems enough for me. However, does
> it make sense to have that user at all? If somebody knows about the
> security implications etc., please speak up.

I'd just do the adduser --system ourselves in the gridengine-common
postinst.  We can then setup the directories properly in postinst etc as
each package requires.  That should be fine.

> Maintainer: is currently set to the not-yet-existing list
> pkg-gridengine-maint at lists.alioth.debian.org, does it make sense to
> create this one (for bug report/upload spam etc), or should we keep
> just use pkg-gridengine-devel?

Personally, unless this becomes very high traffic, I'd just stick to
using the -devel list.

Cheers,

Mark

-- 
Mark Hymers <mhy at debian dot org>

"I once absent-mindedly ordered Three Mile Island dressing in a restaurant
 and, with great presence of mind, they brought Thousand Island Dressing and
 a bottle of chili sauce."
     Terry Pratchett, alt.fan.pratchett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-gridengine-devel/attachments/20070423/ac9fafb6/attachment.pgp