[Pkg-ganeti-devel] Fwd: Ganeti in Debian startup

Leonardo Rodrigues de Mello l at lmello.eu.org
Mon Sep 24 19:36:57 UTC 2007


sorry i had answered just to iustin.

---------- Forwarded message ----------
From: Leonardo Rodrigues de Mello <l at lmello.eu.org>
Date: 24/09/2007 16:36
Subject: Re: [Pkg-ganeti-devel] Ganeti in Debian startup
To: Iustin Pop <iusty at k1024.org>


ok.
so we can create one config file where the user define where is the
directory that will be used to put the os and exports.

we can generate this config file at postinstall of the package, based
on user input (the default entry can be /var/lib/ganeti/os and
/var/lib/ganeti/export. (debconf)
something like /etc/ganeti/ganeti.conf
export_dir = /someplace/export
os_dir = /otherplace/os
what do you think about that ?
.




2007/9/24, Iustin Pop <iusty at k1024.org>:
> On Mon, Sep 24, 2007 at 04:05:05PM -0300, Leonardo Rodrigues de Mello wrote:
> > Sorry for the delay:
> > RCS:  I prefer to use subversion, i don't know how to use git, but i
> > can learn it.
> > LICENSE:  gpl 2 or latter
> >
> > FHS:
> > I believe according to debian policy it would be best to use
> > /var/lib/ganeti since the export is data generated by the program from
> > one instance at a specific time and machine dependent.  os scripts
> > should be put there too.
> > FHS 5.5 page 30.  /usr/share/doc/debian-policy/fhs/fhs.txt.gz
> But neither the export nor the os scripts are machine-dependent - at
> least not the current host. And as I said, I'm afraid that with default
> sizes for var, it will be filled at the first export.
>
> > To implement that, IMHO the best solution is to patch ganeti to use
> > autoconf to specify path for images/os as suggested by Iustin.
> >
> > INIT/CRON:
> > We can patch ganeti init/cron file at package build time to meet our
> > needs.  maybe we can use dpatch (this issue can be used to solve the
> > problem with FHS, if the changes isn't adopted by ganeti upstream
> > code.
> >
> > Mantainer:
> > Cool. Accepted
> >
> >
> > 2007/9/24, Iustin Pop <iusty at k1024.org>:
> > > On Thu, Sep 20, 2007 at 01:04:52PM +0200, Guido Trotter wrote:
> > > >
> > > > Hi!
> > > >
> > > > Sorry for the delay, I sent this message a couple of days ago, unfortunately to
> > > > the wrong list address! :/
> > > >
> > > > So, it's time to get started with packaging Ganeti. The current situation is:
> > > >
> > > > - leonardo has some packages available
> > > > - we have some internal ones
> > > >
> > > > Should we start from leonardo's ones and work on them? The issues we might want
> > > > to discuss, before, are:
> > > >
> > > > Revision Control System:
> > > >   We are currently using subversion, iustin proposed switching to hg or git,
> > > >   what do you think? I had applied for subversion because it's simple, and
> > > >   ganeti is using it, but on the other hand other systems might have some
> > > >   advantages (eg: the possibility of working with code reviews). We need to
> > > >   decide whether to bother the alioth admins again to change or not...
> > > I don't know how much trouble is to change the packages, and how well
> > > the *-buildpackage tools work (e.g. hg-buildpackage, etc.)
> > >
> > > > Licensing:
> > > >   What should we licence the Debian package under? I'm personally against using
> > > >   "GPL2 only" as it means we might have problems if ganeti switches to GPL3 at
> > > >   any point because we won't have control on all the debian part of the code...
> > > >   Nice options would be v2 or later, double licence under v2 and "the same
> > > >   licence as ganeti itself" or just use "the same licence as ganeti itself"...
> > > >   Or we could use BSD and forget about it... Any ideas?
> > > Heh, I didn't know the package needs to be under a specific license.
> > > Let's go for v2 or later.
> > >
> > > > FHS:
> > > >   Before uploading we need to get rid of /srv/ganeti, which we cannot use for
> > > >   packages... Possibilities would be creating it at cluster init time/node add
> > > >   time if it doesn't exist, or moving to /var/share|lib/ganeti... Any other
> > > >   ideas?
> > > Is a package allowed to use /srv/foo but not to package it? Strange...
> > >
> > > I don't have a good option. Maybe a patch to ganeti's autoconf to allow
> > > to specify the actual path of images/OSes.
> > >
> > > Also, I don't know about /var, since the exports can take a lot of space
> > > and it could easily overflow var by mistake.
> > >
> > > > Init/Cron:
> > > >   Ganeti ships scripts which are debian policy compliant, or should anyway...
> > > >   Shall we make debian/rules distribute those rather than copying them and use
> > > >   our own? We can still add patches should we need any!
> > > Yeah, I think so.
> > >
> > > > Maintainer:
> > > >   I'd say "Ganeti Packaging Team <pkg-ganeti-devel at alioth.debian.org>" and the
> > > >   three of us listed as uploaders... Is that cool?
> > > Yes!
> > > >
> > > > Ok, I'm done for now... Waiting for your feedback to start! Thanks!
> > >
> > > Hope this helps,
> > > iustin
> > >
> > > _______________________________________________
> > > Pkg-ganeti-devel mailing list
> > > Pkg-ganeti-devel at lists.alioth.debian.org
> > > http://lists.alioth.debian.org/mailman/listinfo/pkg-ganeti-devel
> > >
> >
> >
> > --
> > Leonardo Rodrigues de Mello
> > jabber: l at lmello.eu.org
> >
>
> _______________________________________________
> Pkg-ganeti-devel mailing list
> Pkg-ganeti-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-ganeti-devel
>


--
Leonardo Rodrigues de Mello
jabber: l at lmello.eu.org


-- 
Leonardo Rodrigues de Mello
jabber: l at lmello.eu.org



More information about the Pkg-ganeti-devel mailing list