Hi, since many years we would like to be able to run piuparts test on more architectures than just amd64, however we never managed to get there, mostly because this is non-trivial and also because both Andreas and myself are too occupied with other stufff, and last not least because noone else seems to be interested to work on this.
The work would need to be done in two areas:
- make piuparts-master aware of multiple architectures and deal with them
- make piuparts-reports create meaningful webpages. This part is actually
the more complicated part of the two.
However, I realized today, that there is a cheap way out:
- rename piuparts.d.o to amd64.piuparts.d.o
- point piuparts.d.o at somewhere sensible (on amd64.piu….d.o)
- setup *another* master for i386.piuparts.d.o and give it an i386 slave or two.
i386 was taken as an example here for any other arch, though i386 is at least
interesting because we still have some i386 only packages in the archive and
because i386 still has a bigger user base than most other archs.
Two more remarks about this new master:
- in theory (and practice to be proven) the master(s) can run on any arch and
doesn't have to match the arch being tested.
- as we would probably only test release not older than jessie on those new
non-amd64 masters, we would need less diskspace on them. (Think 100G not 200G,
as pejacevic uses.)
What do you think? (This shall be an RFC for now, not a request, hence no RT
ticket yet :-)
Alternativly we could also make use of just a single non-amd64 slave and test
on that using a more hackish implementation, namely introducing "sid-i386" and
only test that on i386 and hack that into the amd64 webpages. This would be
less extensible, more hackish and less likely to be turned into something
sensible in reasonable time. (IOW: it will take much longer and will be less
useful until we reach a proper multi-arch setup, as with such a setup I wouldnt
want to test any other suite than sid(-i386) while with a multi master setup
testing more suites on those others arch is both trivial, clean and
straightforward. Having a single master for multiple arches is a also a UI
problem and having several master would avoid that and allow us to to slowly
migrate there.)
Introducing a multi master setup would also be less risky in terms of keeping
piuparts.d.o available for the release team for testing migrations…
And In both cases the longterm goal would be to have a single master host
eventually, it's just that we think the detour via multiple masters would
result in better results faster…
--
cheers,
Holger
signature.asc
Description: Digital signature
