...
Please note - this may change going forward, when VM images are also supported on docker registries.
2.1 App Instance Create
For App Instance Create:
...
As EVE is used more and more in the cloud-native world, this is a practice that people are used to both from docker and kubernetes.
- When the image doesn't exist, obviously it pulls
- When the image does exist:
- Policy is set to "always pull":
- It checks for a new manifest, hashes it, and sees if that hash is different than the current one. If it is, it pulls the entire thing, else it does not (because the hashes prove it is the same)
- Policy is set to "use existing", it does not pull the manifest
- Policy is not set, use default
The definition of "exists" is that whatever is on disk matches the config. If the config was only "ubuntu:latest", then it is that tag. If the config was "ubuntu:latest@sha256:abcdef55511" (i.e. includes a hash), then it validates hash as well.
A similar functionality could be achieved using the following flags:
- “ImagePullPolicy” in Device Config
- This will act as the default Policy for the device.
- The default “Default Policy” ( device.ImagePullPolicy ) will be “Always Pull”
- “ImagePullPolicy” in App Instance Config
- This can be set to override device level policy and specify what needs to be done for the App Instance.
- This ImagePullPolicy can get more detailed, to handle other scenarios than just AppInstance Create, like what to do in case of Image Pull Failure, Should we periodically pull the images, Should image pull happen on each reboot of device or Restart of App Instance etc..
We think at this point, we don’t need all those knobs and just go with the default policy of “Always pull the image” for App Instance Create. If the pull
...
fails, the app instance will fail, even if there is an existing version of the image.
We will implement the ImagePullPolicy knob if there is a future need.
2.2 EVE API for Image Refresh
...