[Piuparts-devel] LogDB refactoring
Andreas Beckmann
anbe at debian.org
Sun May 26 01:02:39 UTC 2013
On 2013-05-25 00:46, Dave Steele wrote:
> 80e8414 packagesdb - Remove obsolete states from PackagesDB.
NACK, see this comment on top of _states:
# FIXME: can we reorder this list or remove entries without breaking the counts.txt for the plot?
> 0a4c208 packagesdb - Remove get_time().
That is not unused:
./piupartslib/packagesdb.py:366: def get_mtime(self):
./piuparts-master-backend.py:249: if stamp_mtime < self._binary_db.get_mtime():
style: Let's try to follow PEP8 if possible, so please
*no* space in parenthesis: f( NONONO ) but f(YESYESYES)
Currently creating a logfile takes a constant number of I/Os,
I'm not fond of making this a linear in n
a slave submits typically 50 logs and does *not* compute the states,
but switches to a different section and computes the state there
(state computation requires knowledge about all logfiles, therefore
bulk loading is advised)
And doing a full logdb initialization for a packagedb creation is
clearly a no-go: upon slave connection we are interested in two things:
age of stampfile and mtime of all subdirs - that is sufficient to decide in
constant I/Os whether a section is idle
Ideally there should only be one instance of a log in
pass/fail/bugged/affected/untestable/reserved, maybe that can be enforced
But for recycle, there is usually a real log somewhere else.
recycle only contains a flag file, and that is useless if there is no real
log that can be recycled (outdated ones get cleaned up in reschedule_old_logs)
using a hardlink of the existing log is cheap because it does not need an
extra inode (touching an------that empty file instead would need another inode)
For upgrade tests, the current solution of ${pkg}_${ver}.log is insufficient
to describe the full upgrade path: currently $ver is taken from the last
distribution (which is more frequently updated than older distros, but not the
only trigger). I would like to chnage this to have the explicit sequence
in the logfile name, although I'm not sure how to actually do this, e.g.
${pkg}_${ver1}_${ver2}_${ver3}.log
That should simplify rerunning the test whenever one of the versions changes.
And request an explicit upgrade path from the slave.
As a special value the string "None" is used to indicate that the package does
not exist in a distro.
Primary use case: A2bpo2B.
Andreas
More information about the Piuparts-devel
mailing list