If we get a storage.LayerUnknown error while committing to local
storage, guess that we tried to reuse a layer in an image that got
deleted in the brief window between when the commit logic decided that
it could reuse the layer, and when it actually tried to create the image
record.
It's tempting to try to resolve this in the image library, but at the
point where this error crops up, it may already have skipped pulling the
relevant layer blob, so the entire copy operation would have to be
restarted from the beginning anyway, and that's the retry package's job.
It's tempting to bake this into the common library's retry package, but
that would require it to "know" about containers/storage, and while in
practice most of its callers already depend on the storage library, that
may a bit much.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
flouthoc
Nalin Dahyabhai