sudo snap restart lxd results in a lot of these messages in the syslog:
Mar 19 21:12:53 ubuntu lxd.daemon[553]: err="No such object" fp=0090de5179e4eb4baeb148ce6f5b9e153a7a09ccaee7ea0df85620c718ad3350 lvl=eror msg="Error getting source image" t=2018-03-19T20:12:53+0000
Mar 19 21:12:53 ubuntu lxd.daemon[553]: err="No such object" fp=00e0c148014f70e2cc863e8dc738c20ed6200aa650b47c57c84db10a4e2826a0 lvl=eror msg="Error getting source image" t=2018-03-19T20:12:53+0000
Mar 19 21:12:53 ubuntu lxd.daemon[553]: err="No such object" fp=00fae0b632a5247f5802a0f61518469efc1cebf2f641d39a73e45ecee2dd3b30 lvl=eror msg="Error getting source image" t=2018-03-19T20:12:53+0000
I suspect the images do not exist anymore on the origin remote (images:)
is there a way to cleanup these unresolved objects?
What is the retention/deletion policy on the images.linuxcontainers.org server? Clever overwrite at every CI?
It’s most likely images you have in your local cache that have since gone away from the image server (we only keep 3 days) and so can’t update. Locally the default is to remove any image you haven’t used in the past 10 days, so it would automatically clean itself up.
But you can also go do that manually by using lxc image list to find the image in question and then remove them with lxc image delete.
thanks for the update. So it’s safer to refer to an alias than directly to an image fingerprint since these are more likely to disappear in the near future (3 days). Or let’s put it in this way, reproducing a same environment with an image fingerprint from a public server is not a usecase.
Yeah, it’s usually recommended to use images:debian/stretch for example rather than images:<some hash> as the latter will only be valid for up to 3 days.
We build around 100GB of images every day and as all our frontends are using very fast PCIe SSDs, it’d get extremely expensive to keep more than a few days of old images.