[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-devel] Documentation regarding HIGHPORT and LOWPORT
- Date: Fri, 15 Jun 2012 07:51:55 -0500
- From: Brian Bockelman <bbockelm@xxxxxxxxxxx>
- Subject: Re: [Condor-devel] Documentation regarding HIGHPORT and LOWPORT
On Jun 15, 2012, at 5:31 AM, Matthew Farrellee wrote:
> On 06/15/2012 12:49 AM, Ziliang Guo wrote:
>> While configuring the test submit machines for NEOS, I ran into what
>> appears to be an error or oversight in the documentation, or a bug in
>> Condor. In section 3.3.1.2 of the manual where we talk about daemon
>> specific configuration, where we use DAEMON.KNOB to specify the daemon
>> the knob is affecting, we use the examples MASTER.HIGHPORT/LOWPORT and
>> NEGOTIATOR.HIGHPORT/LOWPORT. When I attempted to do
>> NEGOTIATOR.HIGHPORT/LOWPORT, the negotiator seemingly ignored the
>> configuration option as the negotiator bound to something completely
>> outside my range. The people I've spoken with theorize that this is
>> because the master is the one creating ports and handing them to the
>> children, and since the HIGHPORT/LOWPORT values were negotiator
>> specific, the master ignored them. If this is the case, then
>> DAEMON.HIGHPORT/LOWPORT would seem more appropriate in the section of
>> nonsensical daemon specific knob examples.
>>
>> My question basically is, was the intent that the master would honor
>> the daemon specific HIGHPORT/LOWPORT knobs for each specified daemon?
>> If so, fine, then we have a bug. If not, then it's probably a good
>> idea to edit the manual to not use HIGHPORT/LOWPORT as examples of
>> valid daemon specific knobs. Of course it's entirely possible that
>> this was valid in the past sometime if the daemons were in charge of
>> creating their own ports to listen on, but I'm finding that the
>> networking section of the documentation can be very, spotty and
>> crufty.
>
> Even if it was intended for DAEMON.HIGH/LOWPORT to work, we should accept it doesn't and fix the documentation to use another example.
>
> HIGH/LOWPORT is on the deprecated spectrum. IN/OUT_HIGH/LOWPORT were the replacements, and they should be on the deprecated spectrum now that we have SHARED_PORT.
>
> Please file a doc ticket for this and other spotty/crufty things you ran into.
>
If SHARED_PORT is "the new way", can we make it default?
Brian