[squid-dev] Drop cache_object protocol support

[Amos Jeffries]

On 26/01/2023 3:30 am, Alex Rousskov wrote:
> On 1/25/23 07:29, Amos Jeffries wrote:
>> On 25/01/2023 5:34 pm, Alex Rousskov wrote:
>>> On 1/24/23 20:57, Amos Jeffries wrote:
>>>> Blocker #2: The squidclient tool still sends cache_object: scheme 
>>>> when given "mgr:" on the CLI. We need to upgrade that first 
>>>
>>> Looks like we are in agreement on that.
>>>
>>>
>>>> and allow admin some time to upgrade before removing the scheme 
>>>> support in squid itself.
>>>
>>> Agreed. Would six months be enough in your opinion? If yes, we may 
>>> be able to remove cache_object support in v6. Otherwise, we can 
>>> remove cache_object support starting with v7 (as far as numbered 
>>> releases are concerned).
>
>> v6 will "feature freeze" in 10 days.
>
> With proper cooperation, 10 days is more than enough to remove 
> cache_object support, but I am not going to fight for that given your 
> resistance.
>
>
>> Early in v7 cycle should be good.
>
> Unless you stop me, I will post a message to squid-users to warn the 
> admins that they should not count on Squid instances supporting 
> cache_object scheme in v7 releases.

Sure. Don't forget to add it to the wiki schedule of deprecated features 
if not already there.

>
>>> IMO, we should not keep any code that is only needed for Squid v3.1 
>>> and earlier. Squid v3.2 and later should http-based cache manager 
>>> access, right? More code always means more maintenance overheads and 
>>> higher change costs. Given our lack of resources, we should start 
>>> ignoring Squid v3 needs.
>>
>> In sentiment I agree. In practicality we have to cope with "LTS" from 
>> vendors, and Squid bugs in the manager.
>
> IMO, LTS vendors and old Squid bugs do not prevent us from removing 
> cache_object support from cachemgr.cgi: The number of admins that 
> match _all_ of the conditions listed below at the same time is negligible.

Evidence needed.

> We should not spend our resources "coping" with those esoteric cases.
>
> 1. Use Squid v3.
> 2. Use Squid v7.
> 3. Use cachemgr.cgi to manage both Squid versions.
> 4. Cannot use cachemgr.cgi from Squid v6.
> 5. Cannot patch cachemgr.cgi v7 to restore cache_object support.

Declaring groups of users "negligible" or "esoteric" without evidence 
just to push your preferred decision is not a valid line of argument.


>
>> v3.2 has http: but the https:, ftp:, whois:, gopher: schemes were 
>> broken until late in the v3.5 series backports.
>> So going by [1] LTS systems still using v3.2 are still a pain.
>
> We can stop that pain any time we want. All it takes is for us to stop 
> mentioning v3 releases when making design decisions like this one. We 
> _choose_ to prolong that pain and to spend scarce resources on a 
> negligible percentage of unimportant use cases instead of spending 
> those resources on popular and important use cases.
>

We are making decisions which affect other peoples lives and employment. 
The "pain" I have been mentioning is _their_ pain, not ours.
It is appropriate to keep the human aspect in mind for this decision and 
utilize the data we do have available.
That data I have says v3.2 and v3.5 are still relevant factors for this 
change.


>
>> For completeness, that MGR_INDEX regression you fixed a short while 
>> ago also means some broken v4/v5 releases may be a pain source during 
>> the transition.
>
> Those releases should not be considered a pain in this context because 
> if that bug is actually important, it will be fixed in those releases.

We can hope. But have no certainty of that. Thus I mentioned it.

>
>> The longer we wait on removal from the CGI and CLI tools (only) the 
>> more seamless it goes. So I am inclined to be very conservative on 
>> the tools capability removal and proactive on ensuring they can cope 
>> with the squid capability loss.
>
> And since there is no way to actually measure "more seamless" or to 
> prove that we are wasting resources on rare unimportant use cases, we 
> end up doing what we do best -- increasing and prolonging pain.
>

We do have at least one measure. I use the count of Vendors distributing 
each problematic release.
Over time their old versions reach EOL, or LTS get updated to new Squid 
versions etc.
We can reasonably expect admin to be using a currently supported version 
of their OS packages.

Amos