function: replace zip_hash with internal logic to see if zips differ

[norbjd]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Context

As of today, we rely on the scaleway_function's zip_hash field and let the user handle the logic if the function code has changed or not (see documentation).

While this is very useful to avoid redeploying the function if the zip has not changed (if zip_hash is the same as the one in the state, don't redeploy), it adds extra logic that is not really something the user wants to manage.

Also, this logic makes it impossible to import a function, as the zip_hash set by terraform import will always be null. As a result, running terraform apply after a terraform import will always trigger a function deployment, even if the zip is exactly the same (but, it's normal, since Terraform has no way to see if the zip matches).

Description

For both reasons described above (degraded UX + import does not work), my proposition is to remove the zip_hash field.

Instead, we can leverage the fact a hash and the size of the zip can be found using the s3 download URL returned by the API.

Example (shell):

# get the download URL of the zip used by the function $FUNCTION_ID
DOWNLOAD_URL=$(curl -X GET -H "X-Auth-Token: $SCW_SECRET_KEY" \
    "https://api.scaleway.com/functions/v1beta1/regions/fr-par/functions/$FUNCTION_ID/download-url" | \
    jq -r '.url')

# get the zip hash and size
curl -v -X GET -r 0-0 $DOWNLOAD_URL 2>&1 | grep '^<'
< HTTP/2 206 
< accept-ranges: bytes
< content-length: 1
< content-range: bytes 0-0/347
< content-type: application/octet-stream
< etag: "09d5c064f79f0eddc012c6d3cf8d35f9"

The last call aims to retrieve content-range and etag fields (s3 common fields), to respectively find the size of the zip (here, 347) and the md5 sum (here, 09d5c064f79f0eddc012c6d3cf8d35f9). Note that we can't send a HEAD request to the download URL of a function, so we have to trick here with -X GET -r 0-0 to get those fields.

To check if the zip has changed, we just have to check if these 2 fields of the local zip matches the ones for the remote zip. While the hash can be enough, we can also decide to the size of the zip to mitigate md5 algorithm weaknesses. Even if it's very unlikely that a user creates a new zip with the exact md5 sum of the old one! Anyway, computing a md5 hash or retrieving the size of a local file is something that can be done pretty quickly in Go.

New or Affected Resource(s)

• scaleway_function

Potential Terraform Configuration

resource "scaleway_function" "function" {
  name     = "func1"
  runtime  = "node20"
  handler  = "handler.handle"
  privacy  = "public"
  zip_file = "func1.zip"
}

We don't need zip_hash field anymore. Terraform provider will detect automatically if the zip differs from the existing one.