Bug 2178953

Thanks for the request, we are looking into providing this.

Pat, to help us understand the requirements properly - is this something you expect to use/integrate with OpenShift, or more of a standalone container?

My primary goal is to drop it into some type of kubernetes.  Not necessarily OpenShift, but I do have a small openshift I might play with it in.

I'm not super interested in running it as a stand alone container, but it might be handy for some folks.

Hi Pat,
I will be working on this. I will prepare testing version of container
and then will contact you whether the testing version suits your needs.

Thanks for your cooperation.

Hi Pat,
i created initial version of container and i would like you to
verify that it suits your needs. You can get the image by executing:
$ podman pull quay.io/tkorbar/squid_testing

I will attach the Dockerfile so you can see all aspects of the image.

Image has exposed ports 3128 and 3130.
3128 port provides cache service and 3130 is reserved for ICP communication
between cache servers should you decide to enable it.
Thus you can start the container with podman run -d --name squid -p 3128:3128 tkorbar/squid_testing

Should you decide to overwrite configuration then simply mount volume to /etc/squid and provide
your own configuration files.

Looking forward to your response.

Created attachment 1955244 [details]
Dockerfile

My local tests show this works the way I'd want it to.  I'd say this is just about perfect for me.

You may want to s/master/primary/ in the Dockerfile.

Hi Pat,
Thanks for your review. I am glad that this fulfills your expectation.
Will inform you about the progress that we will make.

Created attachment 1956081 [details]
Dockerfile

Final version of dockerfile.

Hi Pat,
I am sorry to disturb you again but along the way, i found 2 more improvements
that could be done and i wanted to implement them.
So there are 2 new features:
1. Container is now able to receive additional command line parameters that
   will be supplied to the squid process. For example:
   $ podman run -p 3128:3128 quay.io/tkorbar/squid_testing -u 0

2. Container will now build cache directory if configuration demands so.
   (cache_dir ufs /run/squid/cachedir 100 16 256)
   With this configuration squid would require the cachedir to exist and
   you would have to mount some storage there or rebuild the image.
   Now it is no longer necessary.

As before you can get the container with:
$ podman pull quay.io/tkorbar/squid_testing

I would really appreciate if you could verify that these changes did not
disturb your usecase.

Looking forward to your response.

This works great for me!

(In reply to Pat Riehecky from comment #7)
> My local tests show this works the way I'd want it to.  I'd say this is just
> about perfect for me.
> 
> You may want to s/master/primary/ in the Dockerfile.

Hello,
is it possible to share your local test with us ?  - if it's suitable for upstreaming.
I would add into the upstream testsuite for squid https://src.fedoraproject.org/tests/squid

For testing I just mounted my production squid config into the container and made sure it routed traffic.  I'm not sure how I'd clean it up for public consumption.

Is https://catalog.redhat.com/software/containers/search?q=squid&p=1 supposed to return results?

(In reply to Pat Riehecky from comment #17)
> Is https://catalog.redhat.com/software/containers/search?q=squid&p=1
> supposed to return results?

Hi Pat,
It is not. Squid container is planned for release of RHEL 9.3

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Updated rhel9/squid container image), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2023:6754