fix(compress): allow passing in compressor options

[rchincha]

Goals of this PR:

1. Allow passing in options to individual compressor
2. Do not change default behavior

[rchincha]

An alternative approach to: #508

[rchincha]

https://github.com/project-stacker/stacker/blob/main/pkg/overlay/pack.go#L411C4-L411C4
becomes:

GzipCompressor.WithOpt(GzipBlockLen(256<<12))

[codecov-commenter]

Codecov Report

Merging #509 (029f15e) into main (312b2db) will decrease coverage by 0.04%.
The diff coverage is 50.00%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #509      +/-   ##
==========================================
- Coverage   73.48%   73.45%   -0.04%     
==========================================
  Files          60       60              
  Lines        4884     4893       +9     
==========================================
+ Hits         3589     3594       +5     
- Misses        935      939       +4     
  Partials      360      360              

Files	Coverage Δ
mutate/compress.go	44.92% <50.00%> (+1.59%)	⬆️

[hallyn]

Looks nice

[rchincha]

project-stacker/stacker#529

[rchincha]

@cyphar thoughts on this PR? Hoping to avoid a umoci fork.

[cyphar]

A fork definitely won't be necessary, I'll review this on Monday. Sorry, I was a bit busy last week.

[cyphar]

I'm not sure I like that we ignore invalid arguments here. If we make this act on *gzipCompressor we could make it return a bool (or error) and then the caller can decide if they care about whether WithOpt actually did anything.

Alternatively, it feels like it should be possible to reimplement all of this compressor stuff with a closure that is passed by the caller (that creates the writer and configures it). But that would require more work...

[cyphar]

Maybe we could add a CustomCompressor just for cases where you need to configure the compression? Idk...

[rchincha]

Another place of relevance in umoci code wrt compressor options :(

https://github.com/opencontainers/umoci/blob/main/pkg/system/copy.go#L32

[rchincha]

fyi, filed this against image-spec opencontainers/image-spec#1145

[cyphar]

Given #562 this would need to be reworked, but I don't know if you still have interest in this PR @rchincha? I can carry it if you like. I suspect we would want to make it more like the (... , opts ..func(...))-style configuration pattern now that algorithms are properly supported.

[hallyn]

@cyphar stacker is using this, yes, and AFAIK it is because a user specifically need it.

@mikemccracken can you confirm whether the ability to specify the compression options are still needed?

[mikemccracken]

@cyphar stacker is using this, yes, and AFAIK it is because a user specifically need it.

stacker has this commit in its stale fork of umoci, yes.

@mikemccracken can you confirm whether the ability to specify the compression options are still needed?

For background, here is my summary of how this became necessary, lightly edited from an internal note in 2023:

•	docker and umoci  have different gzip buffer sizes, and **docker build re-compresses base image layers** (this part is weird, but maybe it's because of supporting docker commit).
•	we are seeing this (layers that should be identical not matching) because some app teams are doing docker builds on top of stacker-created base image layers so the base layers don't match after docker recompresses them
•	the Right Fix is to have everyone use stacker, but that won't happen this cycle and we need a fix for this cycle. (note, this is from many cycles ago and nothing has changed)
•	changing stacker to use the same buffer size as docker should be fine and won't cause too much coordination between users of stacker because stacker does not recompress base layers, so old stacker versions can still build with new-stacker created base layers and it won't cause problems

other tools like the containers/image library also match the docker compression option, so they don't have this problem.

---

I believe that the people who were using docker build on top of stacker-built images are still doing so, but I don't know for sure. I do think that it'd come up again if we stopped this but I'm also a little surprised it hasn't come up in other uses of umoci.

Q: Would it make sense to just hardcode in umoci the same compression block size as docker and containers/image use?
It's a workaround for a weird docker behavior but it also seems basically harmless, IIRC the difference was not big vs. the default.

[cyphar]

So, ideally we wouldn't change the current default because doing so would cause the same unfortunate cache busting. However, if Docker really does break our layers then maybe we should just hard-code it...

(It is possible to make the new algorithm setup configurable but it's probably not worth the effort unless there's a strong need for it.)

[mikemccracken]

So, ideally we wouldn't change the current default because doing so would cause the same unfortunate cache busting. However, if Docker really does break our layers then maybe we should just hard-code it...

I don't follow what you mean by cache busting here - AFAIK the only reason this parameter ever comes up is that docker recompresses base tarballs using its own hardcoded blocksize and expects to get the same bits. Are there other tools also doing this?

(It is possible to make the new algorithm setup configurable but it's probably not worth the effort unless there's a strong need for it.)

As for configurability, stacker only needs to match docker, if umoci's default is the same as stacker then we don't need configurability here.

[cyphar]

I meant that if we change the umoci settings then umoci will generate different blobs (with different hashes) compared to previous versions for the same inputs. In practice, OCI images are not built in a fully reproducible way already, but intentionally breaking this is something I try to avoid as much as possible to avoid breaking the caches of layers built with old umoci versions (we have tests to verify we don't do it by accident).

But yeah, if Docker is already forcefully doing this to umoci blobs you import today, then changing it to match is not as big of a deal.

[cyphar]

#581 changes our default to the one used by stacker. PTAL @rchincha.