Re: gnats/gnats mkdb.sh

Re: gnats/gnats mkdb.sh

[Mel Hatzis]

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.

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

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.

--
Mel Hatzis
Juniper Networks, Inc.

Milan Zamazal wrote:
> CVSROOT:	/cvsroot/gnats
> Module name:	gnats
> Changes by:	Milan Zamazal <pdm@zamazal.org>	02/05/26 11:31:27
> 
> Modified files:
> 	gnats          : mkdb.sh 
> 
> Log message:
> 	Ignore remote databases; fixes PR gnats/384; patch by
> 	Lars Henriksen <Lars.Henriksen@netman.dk>.
> 
> CVSWeb URLs:
> http://savannah.gnu.org/cgi-bin/viewcvs/gnats/gnats/gnats/mkdb.sh.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
> 
> 
> _______________________________________________
> Gnats-commit mailing list
> Gnats-commit@gnu.org
> http://mail.gnu.org/mailman/listinfo/gnats-commit
> 




_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: gnats/gnats mkdb.sh

[Lars Henriksen]

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.

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

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

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

Lars Henriksen

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

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.





_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: gnats/gnats mkdb.sh

[Milan Zamazal]

>>>>> "MH" == Mel Hatzis <hatzis@juniper.net> writes:

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

    MH> I agree that this would require careful
    MH> consideration....however, IMO, it's the right solution to the
    MH> problem.

Well, would anyone like to provide appropriate patch?

(I'm going to be busy for another week now, so please pardon me if I
won't answer e-mails right now.  Then I'll attempt once again to get in
synchronization with GNATS bug reports etc. -- if I'm not successful
with it till the end of August, I'll have to resign on maintaining
GNATS. :-( )

Regards,

Milan Zamazal

-- 
And why?

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: gnats/gnats mkdb.sh

[Yngve Svendsen]

At 15:10 30.05.2002 -0700, Mel Hatzis wrote:
>Lars Henriksen wrote:
>>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.

I agree 100% that we should try to phase out the local mode and have 
everything go through gnatsd. I don't think anyone would consider 
installing a daemon-less GNATS 4 server. I think deprecating local mode 
should be a high priority for 4.1, by adjusting the documentation and 
removing options from the tools.

In the meantime, though, I think the fix Lars made should be OK, since the 
manual (and the recently updated man page) clearly states that the path 
field should be empty for databases that are to be accessed through gnatsd. 
Anyway, I'll close PR384 now, since the patch has been committed.

- Yngve 



_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: gnats/gnats mkdb.sh

[Dirk Schenkewitz]

Yngve Svendsen schrieb:
> 
> At 15:10 30.05.2002 -0700, Mel Hatzis wrote:
> >Lars Henriksen wrote:
> >>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.
> 
> I agree 100% that we should try to phase out the local mode and have
> everything go through gnatsd. I don't think anyone would consider
> installing a daemon-less GNATS 4 server. I think deprecating local mode
> should be a high priority for 4.1, by adjusting the documentation and
> removing options from the tools.
> 
> In the meantime, though, I think the fix Lars made should be OK, since the
> manual (and the recently updated man page) clearly states that the path
> field should be empty for databases that are to be accessed through gnatsd.
> Anyway, I'll close PR384 now, since the patch has been committed.

What about communication per mail only ? Does gnatsd also handle this ?
If not, my opinion is clear: please keep this "local mode", because we
cannot live without communication per mail, since gnatsweb cannot be
used in every case.

	dirk
-- 
Dirk Schenkewitz 

InterFace AG                 fon: +49 (0)89 / 610 49 - 126
Leipziger Str. 16            fax: +49 (0)89 / 610 49 - 83
D-82008 Unterhaching         
http://www.interface-ag.de   mailto:dirk.schenkewitz@interface-ag.de


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats