Re: [Condor-devel] Default SHARED_PORT on ? (was - Re: Documentation regarding HIGHPORT and LOWPORT)

[Tim St Clair <tstclair@xxxxxxxxxx>]

I don't mind making this the default as long as the trade off's are explicitly defined (simplicity over performance).  

Cheers,
Tim 


----- Original Message -----
> From: "Matthew Farrellee" <matt@xxxxxxxxxxx>
> To: "Brian Bockelman" <bbockelm@xxxxxxxxxxx>
> Cc: "Condor Developers" <condor-devel@xxxxxxxxxxx>
> Sent: Friday, June 15, 2012 8:07:37 AM
> Subject: [Condor-devel] Default SHARED_PORT on ? (was - Re: Documentation regarding HIGHPORT and LOWPORT)
> 
> On 06/15/2012 08:51 AM, Brian Bockelman wrote:
> >
> > 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
> 
> +1 Default SHARED_PORT on w/o Collector
> 
> https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2622
> 
> Should the Collector be behind the SHARED_PORT by default?
> 
> If so, there are upgrade and configuration complexities that need to
> be
> addressed. IIRC, most resolve around making the collector and all
> collector lookups use ?sock=collector.
> 
> If anyone else is interested, I'll split gt2622 into "make
> shared_port
> default now, w/o collector" and "put collector behind shared_port by
> default, later"
> 
> Best,
> 
> 
> matt
> _______________________________________________
> Condor-devel mailing list
> Condor-devel@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
>