Couple of minor buildfarm issues

Tom Lane wrote:

One pretty silly point: I notice that
http://www.pgbuildfarm.org/index.html
says "The build farm software does not currently run on Windows".
This is out of date no?

Fixed, thanks.

One not so trivial question: do we have a policy about system/compiler
updates on buildfarm members? Arguably, if I'm running say OS X 10.2
and I update to 10.4, it's no longer the same machine and we should
retire the buildfarm ID (the "animal") and issue a new one to denote
that the results aren't necessarily comparable. (I choose the OS X
update as an example with malice aforethought, since in fact our older
branches do not work on 10.4.) Ditto for, say, a major gcc update.

At the very least it seems we need some longitudinal tracking of OS and
compiler and other software versions (eg Python version is relevant to
plpython). As best I can see from here, the identification of a
buildfarm member's software versions is static, and that isn't very
realistic unless we enforce it to be so.

These thoughts do not come upon me as a bolt from the blue. ;-)

The personality of a machine is defined by the tuple of:

<OS, OSVersion, Compiler, CompilerVersion, Architecture>

except that for Linux we say that the OS is the Distribution, not the
kernel (or glibc) version, because when we started somebody (I forget
who) said that the kernel versionwas probably the least interesting
datum. OTOH, in some cases the word "distribution" has been stretched
more than somewhat - Gentoo is really more a "build your own distro"
system than a distribution in itself.

Now, we have several problems with the setup. First, the fields to
describe all these are text fields both on the registration form and
in the database, and there are no edit restrictions or check/FK
constraints. So we have something of a mess, which I need to get around
to cleaning up. Secondly, as you observe, machines change. I have
resisted suggestions to allow arbitrary dynamic updates of personality,
precisely so that we can track history in a sensible fashion. My current
plan is to provide generational personalities only for cases of
OSVersion or CompilerVersion update. Build results will be tied to a
particular generation, and this will be reflected on the history page.
Any other change would require retirement/reregistration. Right now, we
don't have that, and any change in these items should result in member
retirement/reregistration.

We don't consider configuration settings ( e.g.
--enable-integer-datetimes or --with-perl) to be part of the
personality, and we don't currently track changes in them, nor in
versions of third party libraries we might use ( e.g. openssl or libz).
There is a limit to the lengths to which we can reasonably go, and I
feel we are probably not too far from the sweet spot.

Enforcing these details is probably going to be hard. This is mainly a
trust system.

On another note, I am close to having provision for the complete log
upload you requested - my test box has it working and loading into the
db - next I will work on providing web access to it.

cheers

andrew

On Mon, Jul 25, 2005 at 08:49:45AM -0400, Andrew Dunstan wrote:

We don't consider configuration settings ( e.g.
--enable-integer-datetimes or --with-perl) to be part of the
personality, and we don't currently track changes in them, nor in
versions of third party libraries we might use ( e.g. openssl or libz).
There is a limit to the lengths to which we can reasonably go, and I
feel we are probably not too far from the sweet spot.

Well, the config options are always sent back in status reports... maybe
if there was just a summary page that listed what those options were on
a per-report basis; or even maybe diffing between reports to show
changes.

Something else that I think would be good to send back with each status
report is version info for everything relevant. gcc is obvious, I think
the uname stuff reported covers all those bases. I think some linux
distros have a file in /etc that specifies what distro it is, so
including that might be good. Finally, it would be good to include
version info for any external dependancies, especially since this could
change depending on options specified to configure. I suspect that doing
that will involve a change to configure, or maybe adding something to a
makefile that just produces a sumary. Or perhaps the info is available
in config.log. In any case, having a summary of config options and
relevant version info should make it pretty easy to spot changes. Also,
if the info is machine-readable it would be easy to do a summary report
of what different options have how much coverage, etc.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Jim C. Nasby wrote:

On Mon, Jul 25, 2005 at 08:49:45AM -0400, Andrew Dunstan wrote:

We don't consider configuration settings ( e.g.
--enable-integer-datetimes or --with-perl) to be part of the
personality, and we don't currently track changes in them, nor in
versions of third party libraries we might use ( e.g. openssl or libz).
There is a limit to the lengths to which we can reasonably go, and I
feel we are probably not too far from the sweet spot.

Well, the config options are always sent back in status reports... maybe
if there was just a summary page that listed what those options were on
a per-report basis; or even maybe diffing between reports to show
changes.

It's listed at the top of every log page. I am not sure where we should
put it on other pages - the dashboard page is pretty full now - adding 2
or 3 lines per machine to reflect the config options doesn't sound like
a good idea. At one stage I thought of stealing some vertical space for
8 or 10 columns of 10 pixels or so to show the state of the most
importand build flag. I still might do that, if I can standardise the OS
and Compiler info so that they get shorter (e.g. is just knowing that we
have gcc n.m.o enough, or do we need the longer info produced by gcc -v?
I'm inclined to reduce it to n.m.o.)

Something else that I think would be good to send back with each status
report is version info for everything relevant. gcc is obvious, I think
the uname stuff reported covers all those bases. I think some linux
distros have a file in /etc that specifies what distro it is, so
including that might be good. Finally, it would be good to include
version info for any external dependancies, especially since this could
change depending on options specified to configure. I suspect that doing
that will involve a change to configure, or maybe adding something to a
makefile that just produces a sumary. Or perhaps the info is available
in config.log. In any case, having a summary of config options and
relevant version info should make it pretty easy to spot changes. Also,
if the info is machine-readable it would be easy to do a summary report
of what different options have how much coverage, etc.

I have just about finished work on uploading complete logs, and
config.log will contain version info on a lot of 3rd party stuff. For a
sample, see the stage logs listed at
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=oriole&amp;dt=2005-07-25%2017:39:02

I do have one plea, which is that people with ideas review the requested
features tracker on pgfoundry. I keep this up fairly well, even though
some of the items are moderately old. See
http://pgfoundry.org/tracker/?atid=241&amp;group_id=1000040&amp;func=browse

Many of the ideas that have been discussed are already on the list.

cheers

andrew

On Mon, Jul 25, 2005 at 07:06:33PM -0400, Andrew Dunstan wrote:

Well, the config options are always sent back in status reports... maybe
if there was just a summary page that listed what those options were on
a per-report basis; or even maybe diffing between reports to show
changes.

It's listed at the top of every log page. I am not sure where we should
put it on other pages - the dashboard page is pretty full now - adding 2
or 3 lines per machine to reflect the config options doesn't sound like
a good idea. At one stage I thought of stealing some vertical space for
8 or 10 columns of 10 pixels or so to show the state of the most
importand build flag. I still might do that, if I can standardise the OS
and Compiler info so that they get shorter (e.g. is just knowing that we
have gcc n.m.o enough, or do we need the longer info produced by gcc -v?
I'm inclined to reduce it to n.m.o.)

Oh, I wasn't suggesting on the main status page, just in some way that
it's easy to see a) coverage amongst different machines (so this would
show the latest info for each machine) and b) what changes have been
made on a specific machine in the past. I think those two would cover
most cases.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Andrew Dunstan wrote:

At one stage I thought of stealing some vertical space for 8 or 10
columns of 10 pixels or so to show the state of the most importand
build flag. I still might do that, if I can standardise the OS and
Compiler info so that they get shorter (e.g. is just knowing that we
have gcc n.m.o enough, or do we need the longer info produced by gcc
-v? I'm inclined to reduce it to n.m.o.)

I have reduced some of the clutter from OS names/versions and compiler
names/versions, and can reduce some more in the status column, that
means we will be able to have a bunch of flags indicating what build
criteria were used. I am mainly inclined to flag these:

--enable-cassert
--enable-debug
--enable-nls
--enable-integer-datetimes
--with-perl
--with-python
--with-tcl
--with-krb5
--with-openssl

If we have to drop any for reasons of space it would probably be the
first two. Given the fact there are 9 of these I could make it a simple
set of digits [1-9] and provide a legend, although that might not be
quite so visually pleasing.

Any other bids?

cheers

andrew

Given the current issue with the SCO Optimizer and --enable-debug, I'd like
to keep it on the list.

I'd also like to see a way to run both --enable-debug and not --enable-debug
runs either alternately or
With a command line arg.

Same with the --enable-integer-datetimes switch.

Just my $0.02.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US

On Jul 27, 2005, at 11:27 AM, Andrew Dunstan wrote:

I have reduced some of the clutter from OS names/versions and
compiler names/versions,

Out of curiosity, how did you do this? Did you update the original
registration data or make some kind of mapping?

and can reduce some more in the status column, that means we will
be able to have a bunch of flags indicating what build criteria
were used. I am mainly inclined to flag these:

--enable-cassert
--enable-debug
--enable-nls
--enable-integer-datetimes
--with-perl
--with-python
--with-tcl
--with-krb5
--with-openssl

If we have to drop any for reasons of space it would probably be
the first two. Given the fact there are 9 of these I could make it
a simple set of digits [1-9] and provide a legend, although that
might not be quite so visually pleasing.

I'll see if I can't come up with a simple table that can provide
without resorting to numbers. I'm thinking of using abbreviations
such as:

--enable-cassert => assert,
--enable-debug => debug,
--enable-nls => nls,
--enable-integer-datetimes => int-date,
--with-perl => perl,
--with-python => python,
--with-tcl => tcl,
--with-krb5 => krb5,
--with-openssl => ssl,

Michael Glaesemann
grzm myrealbox com

On Jul 27, 2005, at 11:42 AM, Larry Rosenman wrote:

Given the current issue with the SCO Optimizer and --enable-debug,
I'd like
to keep it on the list.

I'd also like to see a way to run both --enable-debug and not --
enable-debug
runs either alternately or
With a command line arg.

Same with the --enable-integer-datetimes switch.

Just my $0.02.

++

(does that make $0.03? $1.03? $1?)

Michael Glaesemann
grzm myrealbox com

Larry Rosenman wrote:

I'd also like to see a way to run both --enable-debug and not --enable-debug
runs either alternately or
With a command line arg.

Same with the --enable-integer-datetimes switch.

In general we don't want you changing the settings much. That goes to
the issue of longitudinal tracking that Tom was talking about the other day.

It can be done, e.g. with an alternate config file. But it's not
recommended.

I am working on some extra debugging assistance - essentially a "run
from source" facility. Jim Nasby has played with it and sent me some
fixes, which I have not had time to try out.

cheers

andrew

Michael Glaesemann wrote:

On Jul 27, 2005, at 11:27 AM, Andrew Dunstan wrote:

I have reduced some of the clutter from OS names/versions and
compiler names/versions,

Out of curiosity, how did you do this? Did you update the original
registration data or make some kind of mapping?

Fixed the original. e.g. 'Linux Debian' and 'Debian Linux' bacame just
'Debian', removed build dates from compiler versions. And so on.

I'll see if I can't come up with a simple table that can provide
without resorting to numbers. I'm thinking of using abbreviations
such as:

--enable-cassert => assert,
--enable-debug => debug,
--enable-nls => nls,
--enable-integer-datetimes => int-date,
--with-perl => perl,
--with-python => python,
--with-tcl => tcl,
--with-krb5 => krb5,
--with-openssl => ssl,

No, it need to be really short. We have maybe 200 pixels to display all
9 flags. So, digits or ticks marks or some such.

Anyway, let's take this offline.

cheers

andrew