#Container.import woes
1 messages · Page 1 of 1 (latest)
hmm I also just hit an error on the first run after ./hack/dev, but it worked the second time 
I wonder if we should just have a separate content store instead of using Buildkit's directly - maybe things are getting GC'd?
Container.import woes
Yeah GC is actually highly possible, content will be removed if there's no lease, and I'm not sure whether we are setting one or not
Second error was different, as it happened while importing rather than while trying to reference it:
input:1: container.import image archive import: unable to resolve platform: content digest sha256:9d1c2cb338f235e0f11b437d2b892a310fa03f1c830363c7bad045d06185a436: not found
so yeah, maybe GC ticked in the middle of the import or something
it's easy enough to just have a second content store, now that "local" can mean engine-side it should be just as fast, but we would need to keep track of its growth I suppose
Yeah, fortunately leases are set via context, so if that's the issue we can most likely fix it ourselves easily
will look into leasing soon (after I catch up on your check progress!)
Going to just add a local content store for now, since I don't want this flaking out during the demo, but maybe we can change it to leases later
Sounds good, when switching back to the main content store, I think what we'll want is a temporary lease (e.g. https://github.com/sipsma/buildkit/blob/cdf28d6fff9583a0b173c62ac9a28d1626599d3b/cache/refs.go#L1226-L1226) and then to do a sync Evaluate of the source op while that lease is held, which will get it into buildkit's cache manager and setup the long-term lease that integrates with the pruning logic: https://github.com/sipsma/buildkit/blob/cdf28d6fff9583a0b173c62ac9a28d1626599d3b/cache/manager.go#L258-L258
After that Evaluate, we can release the temp lease. Doing it that way should in theory ensure it's not gc'd early but also allows it to be gc'd as part of buildkit's pruning, as opposed to either leaking forever or becoming or own problem to manage.