Re: gnats/gnats mkdb.sh

[Mel Hatzis]

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
too.

> > 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
gone unnoticed.

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
>   this:
>
>      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
>   running on.
>
> 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
>
>   default:Bug database:/usr/local/com/gnatsdb:server.juniper.net:1529
>   test:GNATS Test:/homes/hatzis/local/gnats/test:server.juniper.net:1529
>
> 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.

--
Mel Hatzis
Juniper Networks, Inc.