Refactor NewImageSource to add a manifest type abstraction #5743
Conversation
openshift-ci
bot
added
the
kind/cleanup
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: aaronlehmann The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
aaronlehmann
force-pushed
the
refactor-manifest-types
branch
from
f6082d5
to
9f1c553
Compare
Currently, NewImageSource creates a Docker schema2 manifest and an OCI manifest at the same time. This precludes functionality that isn't supported by both manifest types, for example zstd compression. Refactoring this to create only the desired manifest type solves this and also cleans up the code by separating manifest-type-specific code into distinct implementations of a "manifest builder". See discussion in containers#5452. Signed-off-by: Aaron Lehmann <[email protected]>
aaronlehmann
force-pushed
the
refactor-manifest-types
branch
from
9f1c553
to
81fea1d
Compare
|
@mtrmac: PTAL - thanks! |
|
Any possibility of moving this forward? It's a bit frustrating that I was asked to come back and do this refactor, but the PR is not getting reviewed. |
|
@mtrmac have you had a chance to look at this? |
|
@aaronlehmann sorry for the delay. Many of the maintainers are Red Hat based, and we've all been under a big crunch the past few weeks. |
|
@Honny1 Do you happen to have the time to take a look? |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Currently,
NewImageSourcecreates a Docker schema2 manifest and an OCI manifest at the same time. This precludes functionality that isn't supported by both manifest types, for example zstd compression. Refactoring this to create only the desired manifest type solves this and also cleans up the code by separating manifest-type-specific code into distinct implementations of a "manifest builder".How to verify it
Existing tests should suffice since this does not change any semantics, it only cleans up the implementation.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
See discussion in #5452.
Does this PR introduce a user-facing change?