On Wed, Feb 7, 2018 at 10:46 AM, Graham Leggett <[email protected]> wrote: > On 07 Feb 2018, at 5:34 PM, Dirk-Willem van Gulik <[email protected]> > wrote: > > Not sure how this broke on your end - but the cases where I had it break on > me in production where all cases where things were generated and dynamically > registered with some sort of ``service-zone-status-etc-<massively long ipv6 > address>’’ thing: > > casemo-apiservice-backend-frankfurt-production-W0091-2a01-4f80-0201-0000-32e6-0000-0000-0002 > > so chopping of the end is a bit painful. > > > Ideally the hostname should be 256 to match RFC1035, and the balancer name > be larger still to accommodate (512? larger?), but recognise the pain of > being able to backport it.
These are fixed shm strings, IIRC? How is a balancer name >256 characters usable in anything but automated strings, and the example given by Dirk uses nowhere near 256 chars. >From a diagnostics/debugging perspective, nothing is conveyed in a balancer name > 256 (realistically, >80, because it is a single token, but lets be consistent...) that the human can benefit from. In the automated configuration case, at some point, you devolve too much extra data down to a UUID that will be distinct, and be done with it, much as Dirk's example illustrates. On Wed, Feb 7, 2018 at 9:07 AM, Jim Jagielski <[email protected]> wrote: > Personally, I still think that updating these fields for 2.4.x > makes sense and can be justified... but am in no mood > for a battle *grin* As long as the change allows you to compile the backport and rebuild mod_proxy_balancer *alone*... without needing to rebuild all of the consumers, then your change is likely similarly safe for third party modules consuming our API.
