ubuntu-docker-images team mailing list archive

[Sergio Durigan Junior <sergio.durigan@xxxxxxxxxxxxx>]

On Wednesday, August 25 2021, Athos Ribeiro wrote:

> On Tue, Aug 24, 2021 at 05:48:02PM -0400, Sergio Durigan Junior wrote:
>>On Tuesday, August 24 2021, Bryce Harrington wrote:
>
> Hi Sergio and Bryce, Thanks for reviewing this one!

Thanks for working on it!

>>> On Tue, Aug 24, 2021 at 04:05:04PM -0400, Sergio Durigan Junior wrote:
>>>> On Tuesday, August 24 2021, Athos Ribeiro wrote:
>>>>
>>>> > Hello,
>>>> >
>>>> > I have prepared and pushed an initial version for a squid OCI [1].
>>>> >
>>>> > It contains docker-compose and k8s examples and an initial version of
>>>> > the image documentation.
>>>> >
>>>> > While I am still preparing the tests for the image to be included in
>>>> > https://github.com/canonical/server-test-scripts, it would be nice to
>>>> > get an initial review on the new OCI.
>>>>
>>>> Hey again,
>>>>
>>>> Here's the review.
>>>>
>>>> - Dockerfile LGTM.
>>>>
>>>> - entrypoint.sh could do with a few more comments, I think.  Also, I
>>>>   noticed that you implemented the idea we've been discussing, about
>>>>   redirecting the logs to files that are part of volumes exported to the
>>>>   user.  While we certainly should consider this idea, implementing it
>>>>   for squid but not for other images will bring inconsistency to our
>>>>   portfolio.  What do you think?
>
> Squid is a special case where nothing would be written in stdout/stderr
> during the service runtime if we do not try to append those logs there
> somehow. It actually seems that the current approach is maintaining
> consistency with (at least most of) our other images. We could forward
> just the access logs or access+error logs to stdout/stderr though and
> keep the cache logs in the log file only. WDYT?

Yeah, I think it's a good idea.  I like seeing at least some "sign of
life" when I fire up the container, but with squid I was left with
nothing.

BTW, this will also come in handy when you're writing the tests for this
image, because the default way we use to detect whether the container
has successfully started is by grep'ing its output.

Thanks!

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14