...

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. 

1. When the image doesn't exist, obviously it pulls
2. When the image does exist:
1. Policy is set to "always pull":
2. 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)
3. Policy is set to "use existing", it does not pull the manifest
4. 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:

1. “ImagePullPolicy” in Device Config
1. This will act as the default Policy for the device.
2. The default “Default Policy” ( device.ImagePullPolicy ) will be “Always Pull”
2. “ImagePullPolicy” in App Instance Config
1. This can be set to override device level policy and specify what needs to be done for the App Instance.
3. 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

...

1. All VM IMages will have the sha specified for verification
1. Current behavior - no changes here.
2. For Containers:
1. In an Image, User can OPTIONALLY specify SHA of manifest.
1. If specified, this is verified after the manifest is downloaded.
2. If Manifest SHA is NOT Specified
1. Download the manifest, Calculate the SHA and use it for internal purposes ( Image Tracking ).
2. Report the SHA back to the controller in info msg for app instance.
1. In an Image, User can OPTIONALLY specify SHA of manifest.
2. If Manifest SHA is NOT Specified
Need to add an abstraction from ImageID to SHA
3. Need to add an abstraction from ImageObjectID to SHA of the Image.
1. Currently, there is an assumption that IMAGE-OBJECT-ID is unchangeable. This needs to change.
1. This  may be true for VMs also, as we allow the VM image to be stored in a docker registry.
2. In EVE, ImageObjectID needs to be resolved to a SHA
1. Multiple images can resolve to the same SHA.
ImageID
1. ImageObjectID -> SHA is resolved during App Instance Create
1. This can be updated using the “RefreshImage” trigger.
1. Currently, there is an assumption that IMAGE-ID is unchangeable. This needs to change.
In EVE, Image ID needs to be resolved to a SHA

4 APPENDIX - Comment from AVI - Alternate Proposal

...