When pulling images check for stale cached images

[biecho]

Summary

When vHive does pull images, it must check in its local cache if an image is stale. vHive should do this without pulling the whole image again. skopeo is used to only inspect the metadata from a remote image.

[ustiugov]

looks good! however, I am afraid that the image check check would slow down the system if used by default. @biecho could you please measure the added overhead? you can use timestamps printed within log messages, we just need an estimate.

[biecho]

looks good! however, I am afraid that the image check check would slow down the system if used by default. @biecho could you please measure the added overhead? you can use timestamps printed within log messages, we just need an estimate.

Done

[ustiugov]

@biecho great! could you please publish the measurements in this PR?

also, could you please take a look at the test failures (must be very simple), particularly vHive unit tests/ [misc, taps, ...]. The failure is likely due to the repo migration last week. I would really appreciate if you could help fix the problems.

[biecho]

@biecho great! could you please publish the measurements in this PR?

also, could you please take a look at the test failures (must be very simple), particularly vHive unit tests/ [misc, taps, ...]. The failure is likely due to the repo migration last week. I would really appreciate if you could help fix the problems.

Sure I'll publish the measurements as soon as possible. Regarding the vHive unit/tests, I see the following in the logs:

(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 241927 files and directories currently installed.)
Preparing to unpack .../numactl_2.0.12-1_amd64.deb ...
Unpacking numactl (2.0.12-1) ...
Setting up numactl (2.0.12-1) ...
Processing triggers for man-db (2.9.1-1) ...
Cloning into '/usr/local/pmu-tools'...
fatal: could not read Username for 'https://github.com/': No such device or address
Error: Process completed with exit code 128.

I guess this is related to what @EstellaPaula posted on elements.

[cvetkovic]

Can you check how image staleness is checked in containerd? Clone the containerd repo and have a look into ContainerCreate stage of the sandbox creation in code, as well as in the logs. Containerd is already running on the worker node and you can check the performance of ContainerCreate phase in containerd logs. It should be creating queue-proxy container. Look into Estella's writing to see how to find logs.

[ustiugov]

@cvetkovic do you guys still need this patch? if so, can someone take it over?