[0.2] Immutable functions

[rdallman]

With #988 and #1036 in place, we can have immutable function versions with just a little bit more work.

We need to capture the sha of a docker image at upload time so that the docker image cannot change under a certain tag. in the API for a function, the current thinking is that it would be useful as a user to have fields for both the docker image name and tag, in addition to the sha for an image, which fn will need in order to pull the correct image (by sha).

for one, we need to verify that our docker client works when provided with a sha and a registry.

the function definition itself will have:

{
  "name":"myfunc",
  "image":"myuser/myimage:0.0.42",
  "image_id":"sha256:1234fdajlkaf2341kfasfd"
}

the thinking is that clients (fn deploy, primarily) could provide this sha when uploading funcs, though it would be possible for fn server to lookup the sha at update time as well using the registry client, and fn server is likely to have registry credentials as well at some point soon (per #1015), which if done client side the user would have to configure - this seems to make a stronger case for server side looking up the image sha, however in more complex hybrid installs, this may not be possible or savory either, making it more appealing to do in the client. need to resolve this.

usability wise, there is an obvious issue that users who try to re-use a tag will end up getting 'function not found' - this is a behavior that we are strongly trying to discourage for various reasons (uniformity of a function across infrastructure being the largest one, to avoid having 2 versions of an image across runner nodes) - however it's something that users will likely try and maybe there's a nicer way to push them to not do this.

this is something that is not necessarily breaking and could be delayed in the wider 0.2 picture, it is something that is enabled by features added in 0.2 though.

[zootalures]

iirc in docker (last time I read the regexes) there is a canonical naming scheme that includes the tag and the hash - no sure you need the image_id there as the image could just be (iirc)

myuser/myimage:0.0.42@234fdajlkaf2341kfasfd

[zootalures]

ah maybe i've misunderstood -the client would push the sha at the point of production

ignore me

[rdallman]

yea one option is have clients help find shas and enforce the syntax you posted above and/or have an extra field (thanks for note, it would be nice not to add another field). it may well be easier to server side look up the sha for people and add it, if one is not provided, and enforce that constraint there. kind of a UX thing, should make sure it's smooth experience in any event...