[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnats/gnats mkdb.sh
Re: gnats/gnats mkdb.sh
Thu, 30 May 2002 15:10:04 -0700
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020206
Lars Henriksen wrote:
On Wed, May 29, 2002 at 12:19:56PM -0700, Mel Hatzis wrote:
I just noticed this 'fix' and feel compelled to argue against it.
We *NEVER* use the gnats localhost mode...there's no need for it
and IMO it ought to be deprecated. The network mode is perfectly
fine for both local and remote uses.
I take your word for it and tend to agree.
I'm glad you agree...I've noticed that others share this sentiment
This fix effectively breaks mkdb in our environment where all
databases are defined as remote (with host and port specified)
and where the databases file is shared across a large number of
workstations and servers (including the gnats server).
Then it breaks what was broken already. You can't have used mkdb
to create a database in your setup.
Actually, we're still using 4.0 alpha...we have a large GNATS
production environment and if this were broken it would not have
I have done quite a bit of testing of GNATS operating in network
mode on the same host and it holds up well. There are some subtle
differences, but nothing major that couldn't otherwise be addressed.
I made the fix after reading the documentation (Keeping Track,
section 4.2) that explicitly excludes your setup:
For a database that is located across a network, but which should be
accessible from this host, the entry for the database should look like
DATABASE NAME:SHORT DESCRIPTION OF DATABASE::HOSTNAME:PORT
The first two fields are the same as for local databases, the third
field is empty (notice the two adjacent `:' symbols, indicating an
empty field), the fourth field is the hostname of the remote GNATS
server, and the fifth field is the port number that the remote GNATS is
Now, this may be all wrong (and no, I haven't checked the code), but
I agree that the 'fix' to mkdb is according to the documentation, but
I would encourage you to reconsider the documented behaviour.
Supporting two modes is a duplication of effort that gives rise to a
number of the 'arch enemies' of good software engineering....inconsistency,
ambiguity and unnecessary complexity. And in this case, I hold that
it's totally unnecessary.
it does indicate that you may have a problem. I have been on the point
of asking you in another context whether entries like
might be a reason for the faulty behaviour of for example pr-edit.
Some of the problems I've highlighted recently are based on observations
that have unnecessarily constrained my ability to configure gnats.
The 'databases' file is a configuration file...why make changes that limit
the possibility of adding additional configuration options in the future
or constrain how it can be used in the present?
Rather than simply ignore all 'remote' databases, can I suggest
capturing the host field (if it's defined) and checking it against
the current host.
Hmm, this is easier said than done. The host field may contain a DNS
name different from any physical host name. In clusters this may be
further complicated by cluster aliases. But fine with me provided the
"combined" local/remote format really is supported by the code.
I agree that this would require careful consideration....however, IMO,
it's the right solution to the problem.
Juniper Networks, Inc.