Panic when "null" labels are given in deployment about faasd HOT 13 CLOSED

/set title: Error pulling from GitLab.com private registry

from faasd.

Hi @rienafairefr I'm not a GitLab.com user, but I wonder if they have any known issues with containerd? Until recently even GitHub's registry didn't work with containerd and faasd is built with containerd.

go version go1.10.4 linux/amd64

I am noticing that you have Go installed, and a really old version. Why is that? You don't need it to install faasd, but if you built it you must use the minimum version we recommend.

terraform-provider-openfaas

I've not used this provider, perhaps you could use faas-cli deploy/up to confirm that it's working as expected?

I see a large size here, is your disk running out of space? size 34971859

"envVars":{"MAPBOX_API_KEY":"

You may prefer using a secret to env-vars for anything confidential. Do you need to scrub this key from the GitHub issue?

Private registry support is tested and working with the Docker Hub and GitHub's container registry. Maybe @AkihiroSuda has some ideas? @mrsimonemms also has a GitLab account and may be able to help us test / verify with one of his images.

Alex

from faasd.

One thing that stands out to me is how many / slashes you have in your image name. It could be an edge case where some part of the code is expecting a standard image URL i.e. server.com/repo/image:version (x3) instead of registry.gitlab.com/**/**/**/address-modified:openfaas (x5)

from faasd.

One thing that stands out to me is how many / slashes you have in your image name. It could be an edge case where some part of the code is expecting a standard image URL i.e. server.com/repo/image:version (x3) instead of registry.gitlab.com/**/**/**/address-modified:openfaas (x5)

That might be the edge case I'm running into, and why I explicitely didn't redact that detail. In our case, it's a namespace thing for all our images:

registry.gitlab.com/company/project/functions/functiona

registry.gitlab.com/company/project/functions/functionb

registry.gitlab.com/company/project/serviceA
etc ..., because in gitlab you can create groups inside groups, etc, and the docker registry attached to a project gets the same namespace (project is at https://gitlab.com/company/project/functions, then the registry is gitlab.com/company/project/functions)

from faasd.

@alexellis the number slashes look normal - GitLab allows you to have up to three levels on the container registry (which is very useful).

I'll have a dig around later today and let you know what I find

from faasd.

@rienafairefr can you try a top-level image to see if it still breaks that way?

from faasd.

Hi @rienafairefr I'm not a GitLab.com user, but I wonder if they have any known issues with containerd? Until recently even GitHub's registry didn't work with containerd and faasd is built with containerd.

go version go1.10.4 linux/amd64

I am noticing that you have Go installed, and a really old version. Why is that? You don't need it to install faasd, but if you built it you must use the minimum version we recommend.

the go version is the one on the droplet, i didn't install it myself. might be installed as part of the faasd cloud-config, not sure. Might be better to update all that, that's for sure

terraform-provider-openfaas

I've not used this provider, perhaps you could use faas-cli deploy/up to confirm that it's working as expected?

Weirdly, faas deploy seems to work (details below)

I see a large size here, is your disk running out of space? size 34971859

"envVars":{"MAPBOX_API_KEY":"

You may prefer using a secret to env-vars for anything confidential. Do you need to scrub this key from the GitHub issue?

You're right, secret will be better, I'm still trying out ;-) I redacted the api_key, good catch !

Private registry support is tested and working with the Docker Hub and GitHub's container registry. Maybe @AkihiroSuda has some ideas? @mrsimonemms also has a GitLab account and may be able to help us test / verify with one of his images.

Alex

Might not be about the image registry after all:

when the deploy fails (using the api or terraform)
Sep 11 10:49:36 faasd faasd[12711]: 2020/09/11 10:49:36 [Update] request: {"service":"address-modified","image":"registry.gitlab.com/**/**/**/address-modified:openfaas","network":"","envProcess":"sha512sum","envVars":{"MAPBOX_API_KEY":"[redacted]"},"constraints":null,"secrets":null,"labels":null,"annotations":{"CreatedDate":"Mon Sep 3 07:15:55 BST 2018"},"limits":null,"requests":null,"readOnlyRootFilesystem":false}

when the deploy returns 200 ok (using faas deploy):
Sep 11 10:51:28 faasd faasd[12711]: 2020/09/11 10:51:28 [Deploy] request: {"service":"address-modified","image":"registry.gitlab.com/**/**/**/address-modified:openfaas","network":"","envProcess":"node index.js","envVars":{},"constraints":null,"secrets":[],"labels":{},"annotations":{},"limits":null,"requests":null,"readOnlyRootFilesystem":false,"namespace":"openfaas-fn"}
the images are the same, but the rest of the config has differences, not sure what's happenning

from faasd.

So if faas-cli deploy works, it may make sense to raise an issue on the functions terraform provider, which is a third-party component.

I can help with the API call though. Can you share what you're writing into your curl statement? faas-cli deploy just creates a HTTP request, so I'm curious what's going show up here.

Let's format that JSON?

Your first example (terraform)

{
  "service": "address-modified",
  "image": "registry.gitlab.com/**/**/**/address-modified:openfaas",
  "network": "",
  "envProcess": "sha512sum",
  "envVars": {
    "MAPBOX_API_KEY": "[redacted]"
  },
  "constraints": null,
  "secrets": null,
  "labels": null,
  "annotations": {
    "CreatedDate": "Mon Sep 3 07:15:55 BST 2018"
  },
  "limits": null,
  "requests": null,
  "readOnlyRootFilesystem": false
}

Second example: (faas-cli):

{
  "service": "address-modified",
  "image": "registry.gitlab.com/**/**/**/address-modified:openfaas",
  "network": "",
  "envProcess": "node index.js",
  "envVars": {},
  "constraints": null,
  "secrets": [],
  "labels": {},
  "annotations": {},
  "limits": null,
  "requests": null,
  "readOnlyRootFilesystem": false,
  "namespace": "openfaas-fn"
}

from faasd.

I suspect that the code handling something like labels may be expecting a value, where as the terraform provider is giving null instead.

from faasd.

/set title: Panic when "null" labels are given in deployment

from faasd.

I've found the cause of the issue - the last output and the JSON formatting helped with that.

PR #102 is up and when CI passes I'll release it.

For now, include a label in your terraform to get around the issue?

Alex

from faasd.

This closes the issue, adding a label works for deployment ! I chased the most obvious 'difference' in the private registry but that wasn't it. Thanks @alexellis

from faasd.

No problem. Here is your release https://github.com/openfaas/faasd/releases/tag/0.9.4

You may enjoy weekly updates on OpenFaaS including faasd and the other community projects via GitHub Sponsors - https://www.openfaas.com/support - click "Community Insiders Program"

from faasd.