Failures creating a container/image/layer leaves a record in memory

[mtrmac]

layerStore.Put, on various error paths, calls layerStore.Driver.Remove, but not layerStore.Delete; therefore, the failed layer is still kept around in memory and can be found and used within that process (and could even, potentially, be written to disk on any future Save, if that succeeds).

That wouldn’t be that much of an issue of a failure to create a layer always caused a process termination, but that’s not the case for long-lived processes like CRI-O, and even Podman seems to default to 3 retries via c/common/pkg.retry (admittedly in fairly, but not extremely, limited situations).

I’m not sure what all the implications of this are. My head hurts just at the thought of trying to enumerate that.

The “obvious” fix of calling layerStore.Delete on most error paths would test the limits of resiliency of the generic layer the deletion code, and graph drivers’ layer removal code, in previously-possibly-unanticipated ways.

[mtrmac]

The same issue exists for images and containers.

[mtrmac]

This was actually fixed in #1148 , AFAICS.