[Piuparts-devel] [rt.debian.org #4287] a new hope^wpiatti for piuparts.debian.org

Andreas Beckmann anbe at debian.org
Mon May 6 10:12:53 UTC 2013


On 2013-05-06 08:55, Tollef Fog Heen via RT wrote:
> ]] "Holger Levsen via RT" 
> 
>> http://piratenpad.de/p/piatti-wishlist has a hw wishlist discussion for the 
>> new piatti/piuparts setup. 
> 
> It seems to lack anything about memory and CPU, though?

I just documented my experience w.r.t RAM.

>> Besides the questions of hardware-specs and how many slaves we can have, the 
>> most pressing question IMO is how to install piuparts. From git or via 
>> packages. And if packages, where would those come from?
> 
> packages sounds like a good idea in general.  Would it be a problem to
> just run the packages from unstable / backports?

>From a piuparts developer POV I'm clearly in favor of running from git.
Configuration should live in git, and that may even change more
frequently that the code itself - and that has been changing very
frequently recently :-)

For using packages (even if it's only git snapshots being packaged and
installed on piatti), there should be another instance to test them
before they get installed for production. Otherwise every trivial bug
found on piatti will require a package iteration ... which essentially
makes it no different from running directly from git.

The good thing is running from git does not really require writes to
/usr. And we can easily change the setup to not require root for
installing from git (and doing the install separately for slave and
master) after an initial (one-time) setup of the /etc/piuparts symlink ...

For installing dependencies I'd create two additional packages that are
to be installed on new piatti-master and piatti-slave:
  piuparts-master-from-git and piuparts-slave-from-git
(which both come with Conflicts: piuparts, piuparts-master,
piuparts-slave, piuparts-common) - and these could actually do some work
like creating users, creating/chowning directories and symlinks.

For deploying more slaves than just a primary slave we can probably use
packages - once we have seen that some GIT version is running stable on
piatti-slave. And we need to find a solution how to "configure" the
slaves in such a setup. Or even how to handle different architectures
for slaves and hwo to represent them in .conf, -master and -report.
There are probably not that many changes the require a lock-step upgrade
of master and slave.

Andreas

PS: can we shorten /srv/piuparts.debian.org to /srv/piuparts ?



More information about the Piuparts-devel mailing list