Expected Behaviour

A function to show up whilst being deleted, or to be completely removed during deletion.

Current Behaviour

A blank function name is shown in the place of the function being deleted on "faas-cli list" whilst the container is being removed (up to write_timeout seconds)

Steps to Reproduce (for bugs)

1. faas-cli store deploy figlet
2. faas-cli list

alex@alex-nuc8:/tmp$ faas-cli list
Function                      	Invocations    	Replicas
figlet                        	0              	1   

3. faas-cli rm figlet &
4. faas-cli list

alex@alex-nuc8:/tmp$ faas-cli list
Function                      	Invocations    	Replicas
                              	0              	0    

connection from faas-cli to faasd is ok
login, version, deploy. describe seem to work fine:

faas-cli describe hello-py -g faasd.lan:8080
Name:                hello-py
Status:              Ready
Replicas:            1
Available replicas:  1
Invocations:         10
Image:
Function process:
URL:                 http://faasd.lan:8080/function/hello-py
Async URL:           http://faasd.lan:8080/async-function/hello-py

Current Behaviour

faas-cli logs hello-py -g faasd.lan:8080
WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.
Cannot connect to OpenFaaS on URL: http://faasd.lan:8080

Your Environment

• OS and architecture:
  faas-cli on WIN10 / faasd on debian buster / proxmox container

• Versions:

 faas-cli version -g faasd.lan:8080
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|

CLI:
 commit:  40555282492b1f7cfdb10d801fcdce251360ec25
 version: 0.12.9

Gateway
 uri:     http://faasd.lan:8080
 version: 0.18.17
 sha:     18f6c720b50db7da5f9c410f9fd3369ed7aff379
 commit:  Extract a caching function_query type


Provider
 name:          faasd
 orchestration: containerd
 version:       0.9.2
 sha:           5b92e7793dfebbd8e9b1700c2676cc5f56fad83e

containerd -version
containerd github.com/containerd/containerd v1.4.0 09814d48d50816305a8e6c1a4ae3e2bcc4ba725a

uname -a
Linux faasd 5.4.44-2-pve #1 SMP PVE 5.4.44-2 (Wed, 01 Jul 2020 16:37:57 +0200) x86_64 GNU/Linux

Convert over to CNI from netns

Expected Behaviour

This is mentioned in the README, we should use CNI for container networking rather than the nets binary.

Current Behaviour

netns binary which I believe is unmaintained

Possible Solution

There's an open PR from @carlosedp, it would make sense for Carlos to apply the same patch here once tested / released.

alexellis/faas-containerd#18

Context

The README, e2e tests and several blog posts need to be updated to accommodate the change.

Opening this issue to go with the PR. Moving this gist into the docs dir of this repo should make it consistent with the rest of the README and docs. Gist has already been updated to point here.

Gist in question:
https://gist.github.com/alexellis/6d297e678c9243d326c151028a3ad7b9#file-faasd_multipass-md

Expected Behaviour

I have a non-standard setup:

• faasd.lan: local faasd running on debian inside a proxmox container
• faas-reg.lan: local docker registry, the offical docker image
• WIN10: local faas-cli & docker running on windows 10 - Docker Desktop

i followed the hello-python guide.

• login to faasd via faas-cli on WIN10 - OK
• faas-cli new on WIN10 - OK
• build the image on WIN10 - OK
• faas-cli push to faas-reg OK (added faas-reg as insecure registry in Docker)
• faas-cli deploy - FAIL -> tries to pull via httpS

Current Behaviour

faas-cli deploy -f .\hello-py.yml
Deploying: hello-py.
WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.

Unexpected status: 400, message: unable to pull image faas-reg.lan:5000/hello-py:latest: cannot pull: failed to resolve reference "faas-reg.lan:5000/hello-py:latest": failed to do request: Head https://faas-reg.lan:5000/v2/hello-py/manifests/latest: http: server gave HTTP response to HTTPS client

Possible Solution

how do I / where do I / can I specify faas-reg as "insecure registry" for faasd?

faasd configuration setting similar to docker:

  "insecure-registries": [
    "faas-reg.lan:5000"
  ],

Expected Behaviour

faasd install does whatever it was trying to do without error

Current Behaviour

# faasd install
2020/04/05 00:27:02 Writing to: "/var/lib/faasd/secrets/basic-auth-password"
2020/04/05 00:27:02 Writing to: "/var/lib/faasd/secrets/basic-auth-user"
Error: unable to stat /usr/local/bin/faasd, install this binary before continuing

Possible Solution

Instead of hard-coding the path, do the golang equivalent of the_file="$(cd $(dirname "$0") && pwd)/$(basename "$0")" is

Steps to Reproduce (for bugs)

1. vagrant install vagrant-ignition
2. copy the Vagrantfile below into the current directory
3. vagrant up
4. observe the faasd install error

# Vagrantfile
Vagrant.configure("2") do |config|
  config.vm.box = "flatcar-stable"
  config.vm.box_url = "https://stable.release.flatcar-linux.net/amd64-usr/current/flatcar_production_vagrant_virtualbox.json"
  config.vm.network "private_network", ip: "192.168.33.100"

  config.ignition.enabled = true

  $script = <<'SCRIPT'
set -ex
curl -fSLs "https://github.com/openfaas/faasd/releases/download/0.8.1/faasd" --output "./faasd" && chmod a+x "./faasd"
touch resolv.conf
touch prometheus.yml
./faasd install
SCRIPT
  config.vm.provision :shell, inline: $script
end

Context

I was just interested in running faasd to see what it was like, and our fleet of machines is already running containerd on Flatcar

Your Environment

• OS and architecture:

• Versions:

$ uname -a
Linux localhost 4.19.107-flatcar #1 SMP Thu Mar 26 19:48:36 -00 2020 x86_64 Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz GenuineIntel GNU/Linux
$ cat /etc/os-release
NAME="Flatcar Container Linux by Kinvolk"
ID=flatcar
ID_LIKE=coreos
VERSION=2345.3.1
VERSION_ID=2345.3.1
BUILD_ID=2020-03-26-2026
PRETTY_NAME="Flatcar Container Linux by Kinvolk 2345.3.1 (Rhyolite)"
ANSI_COLOR="38;5;75"
HOME_URL="https://flatcar-linux.org/"
BUG_REPORT_URL="https://issues.flatcar-linux.org"
FLATCAR_BOARD="amd64-usr"

Expected Behaviour

faasd should be locally testable using Docker

Current Behaviour

multipass is required

Possible Solution

Install faasd and containerd in a single container together, along with systemd.

Hi there, I'm testing faasd on a local Centos 7 virtualbox VM but I'm stucking on pushing the image after the build.

Expected Behaviour

Image push on Docker Hub and function build

Current Behaviour

Stacking on push to Docker Hub with the following error:
error: failed to solve: rpc error: code = Unknown desc = server message: insufficient_scope: authorization failed

Steps to Reproduce (for bugs)

1. Install faasd and moby/buildkit (OK)
2. faas-cli login (OK)
3. create a folder with a new function (OK):

mkdir myfunc
cd myfunc
faas-cli new myfunc --lang python3

4. edit myfunc.yml image to nicoschi/myfunc:latest (OK)
5. build the function with: faas-cli build -f myfunc.yml --shrinkwrap (OK)
6. create a ~/.docker/config.json with the auth value equal to echo $(echo -n "DOCKERUB_USERNAME:DOCKERUB_PASSWORD" | base64) (OK):

{
 "auths": {
  "https://index.docker.io/v1/": {
   "auth": "myauth"
  }
 }
}

7. start buildkit with: sudo /usr/local/bin/buildkitd & (OK)
8. build the function (KO with error: failed to solve: rpc error: code = Unknown desc = server message: insufficient_scope: authorization failed):

sudo -E /usr/local/bin/buildctl build --frontend dockerfile.v0  \
  --local context=build/myfunc/
  --local dockerfile=build/myfunc/
  --output type=image,name=docker.io/nicoschi/myfunc:latest,push=true

Context

I installed faasd manually using steps in the cloud-config.txt file and buildx starting from this article but as of now I can deploy a new function in the ui from store but i can't deploy and test a custom one created through the faas cli.

Environment

• OS and architecture: Linux 3.10.0-1127.el7.x86_64 / CentOS Linux release 7.8.2003 (Core)

• Versions:

go version
go version go1.13 linux/amd64

containerd -version
containerd github.com/containerd/containerd v1.3.2 ff48f57fc83a8c44cf4ad5d672424a98ba37ded6

uname -a
Linux new-host-3 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7" 

Thanks

We need to update the tags for the Docker images used for the OpenFaaS core components such as the gateway and queue-worker.

Whoever makes this change should also look at what environment variables and configuration items have been introduced and fine-tune accordingly. For instance the queue-worker should now have max_inflight set to something like 5 to enable concurrency.

Acceptance

Testing will need to be performed to show that faasd works as expected after the upgrade. The logs from faasd and faasd-provider will show the version numbers of the components. Please give before/after output.

I have a simple python3 function deployed that adds a print statement in the handler, nothing else in the template is changed. I've invoked it several times.

When SSH to the host and run journalctl -t openfaas-fn:<function name>, I get
no log entries. The end timestamp shown does reflect the last invocation time, but no logs are displayed

journalctl -t openfaas-fn:testsql -- Logs begin at Sun 2020-04-12 23:21:43 EDT, end at Mon 2020-04-13 01:18:31 EDT. - -- No entries --

Your Environment

Ubuntu 118.04.4

• Versions:

go version

go not installed

containerd -version

containerd github.com/containerd/containerd v1.3.2 ff48f57fc83a8c44cf4ad5d672424a98ba37ded6

uname -a

Linux vps262182 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.4 LTS (Bionic Beaver)"

Labels not showing up when running faas-cli describe function

Steps to Reproduce

1. Followed this guide to get faasd running locally with multipass -> https://gist.github.com/alexellis/6d297e678c9243d326c151028a3ad7b9

(I've tried faasd versions: 0.7.7 and 0.7.8)

2. Deploy function with labels:

WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.

Deployed. 200 OK.
URL: http://127.0.0.1:8080/function/figlet

3. Describe deployed function:

Name:                figlet
Status:              Ready
Replicas:            1
Available replicas:  1
Invocations:         4
Image:               
Function process:    
URL:                 http://127.0.0.1:8080/function/figlet
Async URL:           http://127.0.0.1:8080/async-function/figlet

4. Labels are present on server:

[
  {
    "name": "figlet",
    "image": "docker.io/functions/figlet:0.13.0",
    "invocationCount": 4,
    "replicas": 1,
    "envProcess": "",
    "availableReplicas": 0,
    "labels": {
      "testing": "true"
    },
    "annotations": null,
    "namespace": "openfaas-fn"
  }
]

Environment

go version go1.13.4 linux/amd64
containerd -version
containerd containerd.io 1.2.6 894b81a4b802e4eb2a91d1ce216b8817763c29fb
 uname -a
Linux kaderno-XPS-13-9360 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
 cat /etc/os-release
NAME="Ubuntu"
VERSION="19.10 (Eoan Ermine)"

This is probably a problem with me not understanding how to use SSH keys on windows.
If so, please be gentle and point me in the correct direction.

Expected Behaviour

Following the instructions on Windows 10 works

Current Behaviour

I generate an SSH key using PuttyGen
(This is where I think I'm going wrong. I suspect the key isn't in the right place when ssh runs)
Copy the key into the config file and run multipass
Try and ssh into the running instance

c:\faasd>ssh [email protected]
key_load_public: invalid format
The authenticity of host '172.23.19.201 (172.23.19.201)' can't be established.
ECDSA key fingerprint is SHA256:aY6yXLCDk8wSMe6eAJbj5P1fTi9mKCeNBuEzBrlBFJs.
Are you sure you want to continue connecting (yes/no)? yes

Your Environment

• OS and architecture:
  Windows 10

• Versions:
  Latest

The OpenFaaS API can offer CRUD (without the R) for secrets, these can then be mounted into OpenFaaS containers at deployment time.

It would be good to have some consistency here and match the other providers.

How will secrets be stored and mounted? Are we satisfied with the tradeoffs?

Environment variables:

Should people use environment variables, which are also available in plaintext to authenticated users who list functions? Easy to implement, no files on disk, but can find the value by inspecting the container

Flat files:

Not encrypted at rest, but Kubernetes doesn't do this either. May be stored where the basic auth secrets are generated?

Description

Support other container image registries, including private ones

Detail

• Users should be able to deploy public images stored outside of the Docker Hub in third-party registries such as GitLab's public registry or quay.io
• Private images which require authentication to be pulled should also be supported, whether stored on the Docker Hub or a third-party registry

Context

Today faasd only has support for images on the docker.io/ public registry. Other backends for OpenFaaS support this feature including faas-netes and faas-swarm.

faas and faas-containerd do different jobs but can live as one codebase to reduce overhead. They do have some common concerns such as creating containers/tasks and managing network/IPs with CNI.

Expected Behaviour

Add "faasd start-provider" command which would run the code from faas-containerd, perhaps vendoring it, or just copy/pasting it into a new package and archiving the old repo.

I'd imagine a new file in cmd/ and a new package in pkg/provider/

Current Behaviour

We have two binaries to manage, distribute, test, and update.

Steps / solution

• Port code into new packages over from faas-containerd into the faasd tree
• Consolidate documentation and systemd unit files
• Remove instructions for installing faas-containerd as a separate binary
• Consolidate any duplicate code
• Publish a new release of faasd
• Archive faas-containerd

Description

We should make the core openfaas services which are loaded deterministic. With the PR to introduce a docker-compose.yaml the services are parsed into a map which is non-deterministic meaning that the services can attempt to start in the "wrong" order and therefore fail.

This was reported by a user, and I've also run into it whilst updating the cloud-config.txt file

• The gateway depends on NATS and on Prometheus and on the basic-auth-plugin
• The queue worker depends on NATS

Compose files have a depends_on: array that can be given - https://docs.docker.com/compose/compose-file/#compose-file-structure-and-examples

We cannot simply add this and benefit, some work will need to be done in up.go to understand the order and start services accordingly.

Expected Behaviour

Enable basic-auth in faasd install by updating faas-containerd's unit file to set the basic_auth=true env-var.

Current Behaviour

Whilst faas-containerd now supports basic auth, it's disabled by default leaving it vulnerable, even if faasd and the gateway have it enabled.

Possible Solution

Edit https://github.com/alexellis/faasd/blob/master/hack/faas-containerd.service

Steps to Reproduce (for bugs)

1. Deploy via current faasd release
2. See that curl -i host:8080/system/functions has auth - status code 401
3. See that curl -i host:8081/system/functions has no auth - status code 200

To test the fix, carry out step 1 with your new binary and new systemd unit file in place in your GOPATH. i.e. ./faasd install

Then repeat step 2 and step 3 making sure that both have auth enabled now, they should give status code 401.

Testing task

Type: end to end test

Prove that a label is created an then retrieved via the API

Add here:

https://github.com/openfaas/faasd/blob/master/Makefile#L38

Suggested method:

Update the figlet deployment to take a --label key-value and then query it back via faas-cli describe figlet | grep?

Task

Migrate to Go modules

Dep is deprecated now, and go modules should be used with a vendor folder.

Use go build -mod=dep and be careful around the Docker / registry ecosystem as this can cause issues when moving over.

Requirements

This PR must come from an existing contributor to the repo and must be tested.

If a PR is sent in from someone who hasn't read the above, it will probably be closed.

Switch to /var/lib/faasd for working directory to keep persistence

Expected Behaviour

Between reboots we should keep the basic-auth-* files and any other state required.

Current Behaviour

@carlosedp reported that the /var/run/ folder is always deleted upon reboot.

Possible Solution

Move to /var/lib/faasd/ instead

Steps to Reproduce (for bugs)

1. Run faasd install
2. Login
3. Reboot
4. Apparently now the password may be invalid

Description

Use data directory instead of working directory for state

Anywhere where "wd" (working directory) is used, change this for a data directory instead.

• Add --data-dir flag to install and up commands
• Swap out all references to "wd"
• Set the default --data-dir in the systemd unit file for faasd

I assume this would be something like:

/run/faasd/

/var/run appears to be a symlink to /run/ anyway.

While working on:
#40

I had to restart the faasd along with the faasd-provider service to to load the new faasd binary with the changes. With every restart the IP address of the gateway moved up with some value like:

• First run: http://10.62.1.151:8080
• Second run: http://10.62.1.161:8080
• Third run: http://10.62.1.171:8080

It seems like with every restart the containers left on the file system. When hitting the endpoint it load balanced between three figlet containers. Not sure if restarting the service should stop/delete the containers.

Expected Behaviour

Restarting the services should delete all containers.

Current Behaviour

Restarting the services leaves containers.

Possible Solution

I might be restarting something wrong I would need more time to research this but I am opening directly and Issue for the record. If this is not a problem (I am restarting the services the wrong way with systemctl restart faasd && systemctl restart faasd-provider) it might be worth documenting how to properly restart the faasd and faasd-provider services.

Steps to Reproduce (for bugs)

1. Run faasd faasd-provider
2. Deploy figlet with no labels
3. Restart faasd faasd-provider (systemctl)
4. Deploy figlet with labels
5. Start hitting /system/functions and see how figlet with labels and figlet with null labels appear like:

[{"name":"nodeinfo","image":"docker.io/functions/nodeinfo:latest","invocationCount":0,"replicas":0,"envProcess":"","availableReplicas":0,"labels":{"label":"saws"},"annotations":null,"namespace":"openfaas-fn"},{"name":"figlet","image":"docker.io/functions/figlet:0.13.0","invocationCount":0,"replicas":1,"envProcess":"","availableReplicas":0,"labels":{"label":"saws"},"annotations":null,"namespace":"openfaas-fn"}]

[{"name":"nodeinfo","image":"docker.io/functions/nodeinfo:latest","invocationCount":0,"replicas":0,"envProcess":"","availableReplicas":0,"labels":null,"annotations":null,"namespace":"openfaas-fn"},{"name":"figlet","image":"docker.io/functions/figlet:0.13.0","invocationCount":0,"replicas":1,"envProcess":"","availableReplicas":0,"labels":null,"annotations":null,"namespace":"openfaas-fn"}]

Also if you delete function from the UI and reload couple of time the deleted function might show again, due to the backend showing actually container which was spawn before restarting the faasd service.

Context

While working on #40 feature I was confused why it didn't work, but the problem is that the backend was just showing random figlet containers. Had to reload /system/functions couple of times by mistake in order to see that actually I was able to apply the label.

Your Environment

• OS and architecture:
  Ubuntu 18.04
• Versions:

go version
go version go1.12.7 linux/amd64

containerd -version
containerd github.com/containerd/containerd 1.3.0+unknown 

uname -a
Linux mdekov-Lenovo-Y520-15IKBN 5.3.0-28-generic #30~18.04.1-Ubuntu SMP Fri Jan 17 06:14:09 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.2 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.2 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

Add labels to OpenFaas functions from the function spec

Expected Behaviour

We should be able to add a label to a function by adding it to container definition.

So, when we run:
faas-cli store deploy figlet --label hello=world

We should get back the labels with:
faas-cli describe figlet

Current Behaviour

Labels are not added

Possible Solution

A PR is in the works

Steps to Reproduce (for bugs)

1>faas-cli store deploy figlet --label hello=world
2> faas-cli describe figlet # Won't print out labels

This feature works perfectly with faas-netes (OpenFaas running on Kubernetes), but we need to port this functionality here too.

This issue is a duplicate of this issue by @alexellis on the archived faas-containerd repo

The pull-policy flag can be moved into the ProviderConfig struct and read in the read.go file instead of using a flag.

Provider command with a flag:

https://github.com/openfaas/faasd/blob/master/cmd/provider.go#L28

Config package: https://github.com/openfaas/faasd/tree/master/pkg/provider/config

Suggestion via @LucasRoesler

Expected Behaviour

Currently faasd depends on a custom library based on weave net and has netlink/netns dependencies.

The idea is to provide a built-in solution to fetch container IP addresses from CNI configuration and results.

Possible Solution

Use CNI result files parsing the container IP addresses similar to how it's done in https://github.com/rancher/k3c/blob/49e287adc5d011d79bec47b9c75929784b5bc343/pkg/daemon/pod.go#L302

In Slack customer complained about the response of the missing implementation of the log handler it returned:

pi@raspberrypi:~ $ faas-cli logs nslookup --follow --tls-no-verify
Server returned unexpected status code: 500 - log request failed
pi@raspberrypi:~ $ journalctl -u faasd
Feb 16 14:48:59 raspberrypi faasd[325]: [faasd] proxy: http://10.62.0.10:8080/system/logs?follow=true&name=nslookup&tail=-1
Feb 16 14:48:59 raspberrypi faasd[325]: 2020/02/16 13:48:59 Validated request 200.
Feb 16 14:48:59 raspberrypi faasd[325]: 2020/02/16 13:48:59 LogProxy: forwarding request failed: EOF

Expected Behaviour

Return more verbose response, by implementing the LogsHandler from the faas-provider similar to how we do it with namespaces:

Current Behaviour

Log handler is not implemented and returns: log request failed with status code 500

Possible Solution

As explained in Expected Behaviour section. Implement logs handler to return more verbose output for example:

The LogsHandler is not yet implemented.

Steps to Reproduce (for bugs)

1. Deploy faasd
2. Deploy figlet on it
3. Invoke figlet couple of times
4. Run faas-cli logs figlet --follow --tls-no-verify
5. Check the not very explanatory response: Server returned unexpected status code: 500 - log request failed from the CLI here:
   https://github.com/openfaas/faas-cli/blob/30b7cec9634c708679cf5b4d2884cf597b431401/proxy/logs.go#L66

Context

As per the general summary.

Your Environment

• OS and architecture:
  N/A
• Versions:
  N/A

go version
N/A
containerd -version
N/A
uname -a
N/A
cat /etc/os-release
N/A

I hit a timeout of a long function execution

The issue can be reproduced with this: https://github.com/alexellis/go-long

I checked the gateway, it's hard-coded to 60s

The provider has a read/write timeout set of the same value

However, @LucasRoesler suggested that there is also an upstream timeout value that also needs a value and is defaulting to 8-10s.

pi@faasd-pi:~ $ sudo journalctl -f -t faasd
-- Logs begin at Sun 2020-03-08 18:58:18 GMT. --
Apr 16 16:54:27 faasd-pi faasd[16336]: [faasd] proxy: http://10.62.0.210:8080/async-function/make-ca
Apr 16 16:54:39 faasd-pi faasd[16336]: [faasd] proxy: http://10.62.0.210:8080/async-function/make-ca
Apr 16 16:54:40 faasd-pi faasd[16336]: [faasd] proxy: http://10.62.0.210:8080/async-function/make-ca
Apr 16 16:55:24 faasd-pi faasd[16336]: 2020/04/16 15:55:24 Get http://faasd-provider:8081/system/functions: dial tcp: i/o timeout
Apr 16 16:58:54 faasd-pi faasd[16336]: 2020/04/16 15:58:54 Get http://faasd-provider:8081/system/functions: dial tcp: i/o timeout
Apr 16 17:15:59 faasd-pi faasd[16336]: [faasd] proxy: http://10.62.0.210:8080/
Apr 16 17:15:59 faasd-pi faasd[16336]: [faasd] proxy: http://10.62.0.210:8080/ui/
Apr 16 17:15:59 faasd-pi faasd[16336]: 2020/04/16 16:15:59 Validated request 401.
Apr 16 17:15:59 faasd-pi faasd[16336]: [faasd] proxy: http://10.62.0.210:8080/ui/
Apr 16 17:15:59 faasd-pi faasd[16336]: 2020/04/16 16:15:59 Validated request 401.

Expected Behaviour

Stopping faasd and faasd-provider should stop all containers. When the processes faasd and faasd-provider are stopped (with sysctl), it's expected that all containers should be stopped.

Current Behaviour

Some container tasks remain in RUNNING state.

Before stop, all tasks are running:

❯ sc-status faasd-provider
● faasd-provider.service - faasd-provider
   Loaded: loaded (/lib/systemd/system/faasd-provider.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-03-09 08:55:47 EDT; 52s ago
 Main PID: 15197 (faasd)
    Tasks: 8 (limit: 4700)
   Memory: 11.3M (limit: 500.0M)
   CGroup: /system.slice/faasd-provider.service
           └─15197 /usr/local/bin/faasd provider
❯ sc-status faasd
● faasd.service - faasd
   Loaded: loaded (/lib/systemd/system/faasd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-03-09 08:55:47 EDT; 54s ago
 Main PID: 15189 (faasd)
    Tasks: 10 (limit: 4700)
   Memory: 14.5M (limit: 500.0M)
   CGroup: /system.slice/faasd.service
           └─15189 /usr/local/bin/faasd up
❯ sudo ctr task ls
TASK                 PID      STATUS
basic-auth-plugin    15234    RUNNING
nats                 15333    RUNNING
prometheus           15450    RUNNING
gateway              15577    RUNNING
queue-worker         15698    RUNNING

❯ sudo ctr -n openfaas-fn task ls
TASK      PID      STATUS
figlet    15957    RUNNING

After service stop:

❯ sc-stop faasd-provider
❯ sc-stop faasd
❯ sc-status faasd
● faasd.service - faasd
   Loaded: loaded (/lib/systemd/system/faasd.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Mon 2020-03-09 08:57:58 EDT; 2min 46s ago
  Process: 15189 ExecStart=/usr/local/bin/faasd up (code=exited, status=0/SUCCESS)
 Main PID: 15189 (code=exited, status=0/SUCCESS)
❯ sc-status faasd-provider
● faasd-provider.service - faasd-provider
   Loaded: loaded (/lib/systemd/system/faasd-provider.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Mon 2020-03-09 08:57:23 EDT; 3min 23s ago
  Process: 15197 ExecStart=/usr/local/bin/faasd provider (code=killed, signal=TERM)
 Main PID: 15197 (code=killed, signal=TERM)

❯ sudo ctr -n openfaas-fn task ls
TASK      PID      STATUS
figlet    15957    RUNNING
❯ sudo ctr task ls
TASK            PID      STATUS
prometheus      15450    STOPPED
gateway         15577    RUNNING
queue-worker    15698    RUNNING

As seen, the deployed function, figlet and the containers gateway and queue-worker still had their tasks running.

Below the stop logs:

Mar 09 09:16:51 debian10 faasd[16313]: 2020/03/09 09:16:51 Signal received.. shutting down server in 1s
Mar 09 09:16:51 debian10 faasd[16313]: 2020/03/09 09:16:51 [Delete] removing CNI network for: basic-auth-plugin
Mar 09 09:16:51 debian10 faasd[16313]: 2020/03/09 09:16:51 [Delete] removed: basic-auth-plugin from namespace: /proc/16360/ns/net, ID: basic-auth-plugin-16360
Mar 09 09:16:51 debian10 faasd[16313]: Status of basic-auth-plugin is: running
Mar 09 09:16:51 debian10 faasd[16313]: 2020/03/09 09:16:51 Need to kill basic-auth-plugin
Mar 09 09:16:51 debian10 faasd[16313]: 2020/03/09 09:16:51 [Delete] removing CNI network for: nats
Mar 09 09:16:52 debian10 faasd[16313]: 2020/03/09 09:16:52 [Delete] removed: nats from namespace: /proc/16460/ns/net, ID: nats-16460
Mar 09 09:16:52 debian10 faasd[16313]: Status of nats is: running
Mar 09 09:16:52 debian10 faasd[16313]: 2020/03/09 09:16:52 Need to kill nats
Mar 09 09:16:52 debian10 faasd[16313]: [1] 2020/03/09 13:16:52.145386 [INF] STREAM: Shutting down.
Mar 09 09:16:52 debian10 faasd[16313]: [1] 2020/03/09 13:16:52.145588 [INF] Server Exiting..
Mar 09 09:16:52 debian10 faasd[16313]: 2020/03/09 09:16:52 [Delete] removing CNI network for: prometheus
Mar 09 09:16:52 debian10 faasd[16313]: 2020/03/09 09:16:52 [Delete] removed: prometheus from namespace: /proc/16578/ns/net, ID: prometheus-16578
Mar 09 09:16:52 debian10 faasd[16313]: Status of prometheus is: running
Mar 09 09:16:52 debian10 faasd[16313]: 2020/03/09 09:16:52 Need to kill prometheus
Mar 09 09:16:52 debian10 faasd[16313]: level=warn ts=2020-03-09T13:16:52.417Z caller=main.go:501 msg="Received SIGTERM, exiting gracefully..."
Mar 09 09:16:52 debian10 faasd[16313]: level=info ts=2020-03-09T13:16:52.417Z caller=main.go:526 msg="Stopping scrape discovery manager..."
Mar 09 09:16:52 debian10 faasd[16313]: level=info ts=2020-03-09T13:16:52.417Z caller=main.go:540 msg="Stopping notify discovery manager..."
Mar 09 09:16:52 debian10 faasd[16313]: level=info ts=2020-03-09T13:16:52.417Z caller=main.go:562 msg="Stopping scrape manager..."
Mar 09 09:16:52 debian10 faasd[16313]: level=info ts=2020-03-09T13:16:52.417Z caller=main.go:522 msg="Scrape discovery manager stopped"
Mar 09 09:16:52 debian10 faasd[16313]: level=info ts=2020-03-09T13:16:52.417Z caller=main.go:536 msg="Notify discovery manager stopped"
Mar 09 09:16:52 debian10 faasd[16313]: level=info ts=2020-03-09T13:16:52.417Z caller=manager.go:814 component="rule manager" msg="Stopping rule manager..."
Mar 09 09:16:52 debian10 faasd[16313]: level=info ts=2020-03-09T13:16:52.417Z caller=manager.go:820 component="rule manager" msg="Rule manager stopped"
Mar 09 09:16:52 debian10 faasd[16313]: level=info ts=2020-03-09T13:16:52.417Z caller=main.go:556 msg="Scrape manager stopped"
Mar 09 09:16:52 debian10 faasd[16313]: level=info ts=2020-03-09T13:16:52.418Z caller=notifier.go:602 component=notifier msg="Stopping notification manager..."
Mar 09 09:16:52 debian10 faasd[16313]: level=info ts=2020-03-09T13:16:52.419Z caller=main.go:727 msg="Notifier manager stopped"
Mar 09 09:17:07 debian10 faasd[16313]: Disconnected from nats://nats:4222
Mar 09 09:17:07 debian10 faasd[16313]: Reconnect
Mar 09 09:17:07 debian10 faasd[16313]: Connect: nats://nats:4222
Mar 09 09:17:09 debian10 faasd[16313]: Reconnecting (1/120) to nats://nats:4222 failed
Mar 09 09:17:09 debian10 faasd[16313]: Waiting 2s before next try
Mar 09 09:17:10 debian10 faasd[16313]: 2020/03/09 13:17:10 Disconnected from nats://nats:4222
Mar 09 09:17:10 debian10 faasd[16313]: 2020/03/09 13:17:10 Reconnect
Mar 09 09:17:10 debian10 faasd[16313]: 2020/03/09 13:17:10 Connect: nats://nats:4222
Mar 09 09:17:11 debian10 faasd[16313]: Connect: nats://nats:4222
Mar 09 09:17:12 debian10 faasd[16313]: 2020/03/09 13:17:12 Reconnecting (1/60) to nats://nats:4222 failed
Mar 09 09:17:13 debian10 faasd[16313]: Reconnecting (2/120) to nats://nats:4222 failed
Mar 09 09:17:13 debian10 faasd[16313]: Waiting 4s before next try
Mar 09 09:17:14 debian10 faasd[16313]: 2020/03/09 13:17:14 Connect: nats://nats:4222
Mar 09 09:17:16 debian10 faasd[16313]: 2020/03/09 13:17:16 Reconnecting (2/60) to nats://nats:4222 failed
Mar 09 09:17:18 debian10 faasd[16313]: Connect: nats://nats:4222
Mar 09 09:17:20 debian10 faasd[16313]: Reconnecting (3/120) to nats://nats:4222 failed
Mar 09 09:17:20 debian10 faasd[16313]: Waiting 6s before next try
Mar 09 09:17:20 debian10 faasd[16313]: 2020/03/09 13:17:20 Connect: nats://nats:4222
Mar 09 09:17:22 debian10 faasd[16313]: error deleting container prometheus, prometheus, cannot delete running task prometheus: failed precondition
Mar 09 09:17:22 debian10 faasd[16313]: 2020/03/09 09:17:22 [proxy] Done received
Mar 09 09:17:22 debian10 faasd[16313]: 2020/03/09 13:17:22 Reconnecting (3/60) to nats://nats:4222 failed
Mar 09 09:17:23 debian10 systemd[1]: faasd.service: Succeeded.

Possible Solution

Steps to Reproduce (for bugs)

1. Start faasd and faasd-provider
2. Deploy a function
3. Stop faasd and faasd-provider
4. Check container tasks with sudo ctr -n openfaas-fn task ls and sudo ctr task ls.

Context

Your Environment

• OS and architecture: Linux debian10 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux

Latest faasd built from master.

Currently the secrets are created if they dont exist, but they are never changed.

We need some way for a user to easily reset secrets, and possibly reload the containers that rely on them if they are running?

Expected Behaviour

A command to change the saved secret, or we can recreate every time?

Current Behaviour

Secrets static once created and dont change. A user would have to manually remove the file in the working dir

Possible Solution

Command to remove the file? It recreate it?

Steps to Reproduce (for bugs)

Context

Your Environment

• OS and architecture:

• Versions:

go version

containerd -version

uname -a

cat /etc/os-release

Is the code to keep containers hot kept in this repo or is it part of the main OpenFaaS system?

On a whim, tried to build this under a jessie based Raspberry Pi system, and got a build failure with the error that the minimum required version of libseccomp is v2.2.0 and jessie only provides 2.1.1.

Not readily possible to fix, and it's time to upgrade that system in any case, so this is just a word of note to anyone building this that there's that dependency.

Redirect core services logs to journalctl

Expected Behaviour

faasd should only show log lines for the output it prints, instead of for any containers it runs from the docker-compose.yaml file.

We should then be able to access the logs from journalctl in a similar way to how we do this for functions

Current Behaviour

The logs are intermingled between faasd itself and the containers it's managing and is confusing.

Possible Solution

Copy the approach used for running a function's container, which redirects its logs to the journal.

Currently it is possible to provision a faasd installation on digitalocean using terraform by following the steps in Terraform for DigitalOcean.
The idea is to extend this to provision a production-ready faasd installation by adding TLS support out of the box.

Expected Behaviour

A faasd installation with TLS support is provisioned when applying the terraform plan.

Current Behaviour

No TLS support for the provisioned droplet

Possible Solution

• Use Caddy for automatic TLS certificates' provisioning
• Automate DNS record creation when domain is managed by digitalocean?

Description

We need a volunteer to update all the guides, terraform automation and cloud-config.txt to use the release 0.9.0

The assets are in this repo, so you shouldn't have too hard of a time finding stuff. Bear in mind we now have a dependency on docker-compose.yaml and that may need to be downloaded before faasd install.

Feel free to ask questions here.

The new cloud-config.txt will need to be tested with evidence that it is using the new version - see journalctl for the logs which prints a version from faasd.

As a new developer I would like to stand up an environment in a limited number of steps to start iterating on new code.

Proposal

Below is a first pass at standing up a VM in multipass with some helper scripts for syncing the project and redeploying from source.

master...gabeduke:master

Steps to validate (check out my fork):

1. make multipass-run (type yes when the prompt shows up to add pub key)
2. make ssh will rsync the repository to the appropriate place inside the multipass VM's GOPATH then ssh into the directory
3. make dev will rsync the repository into the multipass VM, build the go package and switch the new binary out with the running systemd service

Your Environment

• OS and architecture:
  tested on Ubuntu 19.10 x86_64

How do we reduce duplication of installation steps?

All of the below, along with additional steps in https://github.com/jsiebens/rpi-faasd duplicate installation steps for containerd, CNI and other components / files:

https://github.com/openfaas/faasd/blob/master/docs/bootstrap/digitalocean-terraform/cloud-config.tpl
https://github.com/openfaas/faasd/blob/master/docs/bootstrap/cloud-config.tpl
https://github.com/openfaas/faasd/blob/master/cloud-config.txt

I'd be interested in suggestions from the community.

What about a parameterised bash file, that each of the automation tools could use, perhaps with parameters where needed for things like the gateway password?

Any work we do here will also benefit RPi users, who currently need to run all the steps manually, or install cloud-init and then update the above templates.

https://blog.alexellis.io/faasd-for-lightweight-serverless/

Hello!
How can I set limits for functions? I tried this

version: 1.0
provider:
  name: openfaas
  gateway: http://127.0.0.1:8080
functions:
  hello-world:
    lang: python3
    handler: ./hello-world
    image: test/hello-world:latest
    limits:
      memory: 1Mi
    requests:
      memory: 1Mi

And this

version: 1.0
provider:
  name: openfaas
  gateway: http://127.0.0.1:8080
functions:
  hello-world:
    lang: python3
    handler: ./hello-world
    image: test/hello-world:latest
    limits:
      memory: 1m
    requests:
      memory: 1m

And it doesn't work.

Expected Behaviour

Function is created :-)

Current Behaviour

Function is not created :-(
faasd / faasd-provider shows a panic

Sep 11 10:08:50 faasd faasd[12711]: 2020/09/11 10:08:50 [Deploy] 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}
Sep 11 10:08:51 faasd faasd[12719]: [faasd] proxy: http://10.62.0.6:8080/system/function/test-analysis
Sep 11 10:08:51 faasd faasd[12719]: 2020/09/11 10:08:51 Validated request 200.
Sep 11 10:08:51 faasd faasd[12719]: 2020/09/11 10:08:51 Forwarded [GET] to /system/function/test-analysis - [404] - 0.001787s seconds
Sep 11 10:08:51 faasd faasd[12711]: 2020/09/11 10:08:51 Deploy registry.gitlab.com/**/**/*/address-modified:openfaas size: 34971859
Sep 11 10:08:51 faasd faasd[12711]: 2020/09/11 10:08:51 http: panic serving 10.62.0.6:38720: runtime error: invalid memory address or nil pointer dereference
Sep 11 10:08:51 faasd faasd[12711]: goroutine 153253 [running]:
Sep 11 10:08:51 faasd faasd[12711]: net/http.(*conn).serve.func1(0xc000473860)
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/.gimme/versions/go1.13.linux.amd64/src/net/http/server.go:1767 +0x139
Sep 11 10:08:51 faasd faasd[12711]: panic(0xd4a000, 0x15bd3d0)
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/panic.go:679 +0x1b2
Sep 11 10:08:51 faasd faasd[12711]: github.com/openfaas/faasd/pkg/provider/handlers.deploy(0xfaaa00, 0xc0005637a0, 0xc00045ac60, 0x10, 0xc000c77f80, 0x55, 0x0, 0x0, 0xc00045ac70, 0x9, ...)
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/gopath/src/github.com/openfaas/faasd/pkg/provider/handlers/deploy.go:111 +0x867
Sep 11 10:08:51 faasd faasd[12711]: github.com/openfaas/faasd/pkg/provider/handlers.MakeDeployHandler.func1(0xfa6a40, 0xc0002c8fc0, 0xc000c78300)
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/gopath/src/github.com/openfaas/faasd/pkg/provider/handlers/deploy.go:58 +0x47f
Sep 11 10:08:51 faasd faasd[12711]: net/http.HandlerFunc.ServeHTTP(...)
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/.gimme/versions/go1.13.linux.amd64/src/net/http/server.go:2007
Sep 11 10:08:51 faasd faasd[12711]: github.com/openfaas/faasd/vendor/github.com/openfaas/faas-provider/auth.DecorateWithBasicAuth.func1(0xfa6a40, 0xc0002c8fc0, 0xc000c78300)
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/gopath/src/github.com/openfaas/faasd/vendor/github.com/openfaas/faas-provider/auth/basic_auth.go:28 +0x272
Sep 11 10:08:51 faasd faasd[12711]: net/http.HandlerFunc.ServeHTTP(0xc0002f2c80, 0xfa6a40, 0xc0002c8fc0, 0xc000c78300)
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/.gimme/versions/go1.13.linux.amd64/src/net/http/server.go:2007 +0x44
Sep 11 10:08:51 faasd faasd[12711]: github.com/openfaas/faasd/vendor/github.com/gorilla/mux.(*Router).ServeHTTP(0xc0002ca000, 0xfa6a40, 0xc0002c8fc0, 0xc000c78100)
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/gopath/src/github.com/openfaas/faasd/vendor/github.com/gorilla/mux/mux.go:212 +0xe2
Sep 11 10:08:51 faasd faasd[12711]: net/http.serverHandler.ServeHTTP(0xc0002c81c0, 0xfa6a40, 0xc0002c8fc0, 0xc000c78100)
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/.gimme/versions/go1.13.linux.amd64/src/net/http/server.go:2802 +0xa4
Sep 11 10:08:51 faasd faasd[12711]: net/http.(*conn).serve(0xc000473860, 0xfaa940, 0xc000c9da00)
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/.gimme/versions/go1.13.linux.amd64/src/net/http/server.go:1890 +0x875
Sep 11 10:08:51 faasd faasd[12711]: created by net/http.(*Server).Serve
Sep 11 10:08:51 faasd faasd[12711]:         /home/travis/.gimme/versions/go1.13.linux.amd64/src/net/http/server.go:2927 +0x38e
Sep 11 10:08:51 faasd faasd[12719]: 2020/09/11 10:08:51 error with upstream request to: /system/functions, Post http://faasd-provider:8081/system/functions: EO

Your Environment

• OS and architecture:
  deploying the functions through terraform-provider-openfaas, but the error is the same with direct API on the gateway
  faasd is deployed on a digitalocean droplet with the cloud-config template https://raw.githubusercontent.com/openfaas/faasd/master/docs/bootstrap/digitalocean-terraform/cloud-config.tpl

• Configurations
  the docker auth config was copied

root@faasd:/var/lib/faasd# cat /var/lib/faasd/.docker/config.json 
{
    "auths": {
        "registry.gitlab.com": {
            "auth": "*****"
        }
    }
}

the auth is identical to ~/.docker/config.json on my laptop, which can pull the registry.gitlab.com/**/**/**/address-modified:openfaas image without issues.

• Versions:

go version
go version go1.10.4 linux/amd64

containerd -version
containerd github.com/containerd/containerd v1.3.5 9b6f3ec0307a825c38617b93ad55162b5bb94234

uname -a
Linux faasd 4.15.0-115-generic #116-Ubuntu SMP Wed Aug 26 14:04:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

Interesting

not sure of where (before, after, during) in the deploy this happens, maybe it's unrelated, but I see this in the logs of faasd:

Sep 11 10:07:34 faasd faasd[12711]: 2020/09/11 10:07:34 Unsolicited response received on idle HTTP channel starting with "HTTP/1.0 400 Bad Request\nCache-Control: no-cache\nConnection: close\nContent-Type: text/html\n\n<!DOCTYPE html>\n<html>\n<head>\n  <meta content=\"width=device-width, initial-scale=1, maximum-scale=1\" name=\"viewport\">\n  <title>400 Bad Request</title>\n  <style>\n    body {\n      color: #666;\n      text-align: center;\n      font-family: \"Helvetica Neue\", Helvetica, Arial, sans-serif;\n      margin: auto;\n      font-size: 14px;\n    }\n\n    h1 {\n      font-size: 56px;\n      line-height: 100px;\n      font-weight: normal;\n      color: #456;\n    }\n\n    h2 {\n      font-size: 24px;\n      color: #666;\n      line-height: 1.5em;\n    }\n\n    h3 {\n      color: #456;\n      font-size: 20px;\n      font-weight: normal;\n      line-height: 28px;\n    }\n\n    hr {\n      max-width: 800px;\n      margin: 18px auto;\n      border: 0;\n      border-top: 1px solid #EEE;\n      border-bottom: 1px solid white;\n    }\n\n    img {\n      max-width: 40vw;\n    }\n\n    .container {\n      margin: auto 20px;\n    }\n  </style>\n</head>\n\n<body>\n  <h1>\n    <img src=\"data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMjEwIiBoZWlnaHQ9IjIxMCIgdmlld0JveD0iMCAwIDIxMCAyMTAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+CiAgPHBhdGggZD0iTTEwNS4wNjE0IDIwMy42NTVsMzguNjQtMTE4LjkyMWgtNzcuMjhsMzguNjQgMTE4LjkyMXoiIGZpbGw9IiNlMjQzMjkiLz4KICA8cGF0aCBkPSJNMTA1LjA2MTQgMjAzLjY1NDhsLTM4LjY0LTExOC45MjFoLTU0LjE1M2w5Mi43OTMgMTE4LjkyMXoiIGZpbGw9IiNmYzZkMjYiLz4KICA8cGF0aCBkPSJNMTIuMjY4NSA4NC43MzQxbC0xMS43NDIgMzYuMTM5Yy0xLjA3MSAzLjI5Ni4xMDIgNi45MDcgMi45MDYgOC45NDRsMTAxLjYyOSA3My44MzgtOTIuNzkzLTExOC45MjF6IiBmaWxsPSIjZmNhMzI2Ii8+CiAgPHBhdGggZD0iTTEyLjI2ODUgODQuNzM0Mmg1NC4xNTNsLTIzLjI3My03MS42MjVjLTEuMTk3LTMuNjg2LTYuNDExLTMuNjg1LTcuNjA4IDBsLTIzLjI3MiA3MS42MjV6IiBmaWxsPSIjZTI0MzI5Ii8+CiAgPHBhdGggZD0iTTEwNS4wNjE0IDIwMy42NTQ4bDM4LjY0LTExOC45MjFoNTQuMTUzbC05Mi43OTMgMTE4LjkyMXoiIGZpbGw9IiNmYzZkMjYiLz4KICA8cGF0aCBkPSJNMTk3Ljg1NDQgODQuNzM0MWwxMS43NDIgMzYuMTM5YzEuMDcxIDMuMjk2LS4xMDIgNi45MDctMi45MDYgOC45NDRsLTEwMS42MjkgNzMuODM4IDkyLjc5My0xMTguOTIxeiIgZmlsbD0iI2ZjYTMyNiIvPgogIDxwYXRoIGQ9Ik0xOTcuODU0NCA4NC43MzQyaC01NC4xNTNsMjMuMjczLTcxLjYyNWMxLjE5Ny0zLjY4NiA2LjQxMS0zLjY4NSA3LjYwOCAwbDIzLjI3MiA3MS42MjV6IiBmaWxsPSIjZTI0MzI5Ii8+Cjwvc3ZnPgo=\" alt=\"GitLab Logo\" /><br />\n    400\n  </h1>\n  <div class=\"container\">\n    <h3>Your browser sent an invalid request.</h3>\n    <hr />\n    <p>Please contact your GitLab administrator if you think this is a mistake.</p>\n  </div>\n</body>\n</html>\n<html>\n"; err=<nil>

Which is a 400 bad request HTML from gitlab, so faasd or faasd-provider is making a request to the registry with wrong informations

I just started playing with faasd, and was able to install faasd. However, can't access the Prometheus gateway or perform any other operation inside the VM. Is there a way to be to access the private IPs from outside the VM. Like Docker allows port-mapping, is there anything similar available?

Expected Behaviour

Trying to figure out if there is a way to be able to access private IPs from outside the Ubuntu VM on Mac.

http://[prometheus_ip]:9090/targets

Current Behaviour

Possible Solution

Steps to Reproduce (for bugs)

Context

journalctl -u faasd -f
-- Logs begin at Wed 2019-08-07 18:19:05 UTC. --
Jan 29 06:33:02 ubuntu faasd[25004]: Connect: nats://nats:4222
Jan 29 06:33:02 ubuntu faasd[25004]: Subscribing to: faas-request at nats://nats:4222
Jan 29 06:33:02 ubuntu faasd[25004]: Wait for  5m5s
Jan 29 06:33:02 ubuntu faasd[25004]: [1] 2020/01/29 06:33:02.336483 [INF] STREAM: Channel "faas-request" has been created
Jan 29 06:33:02 ubuntu faasd[25004]: Listening on [faas-request], clientID=[faas-worker-ubuntu], qgroup=[faas] durable=[]
Jan 29 06:33:05 ubuntu faasd[25004]: 2020/01/29 06:33:05 [up] Sending 10.62.0.5 to proxy
Jan 29 06:33:05 ubuntu faasd[25004]: 2020/01/29 06:33:05 Starting faasd proxy on 8080
Jan 29 06:33:05 ubuntu faasd[25004]: Gateway: 10.62.0.5:8080
Jan 29 06:33:05 ubuntu faasd[25004]: 2020/01/29 06:33:05 [proxy] Wait for done
Jan 29 06:33:05 ubuntu faasd[25004]: 2020/01/29 06:33:05 [proxy] Begin listen on 8080

Your Environment

• OS and architecture:
  Mac OSX, Installed faasd in Ubuntu 18.04

• Versions:

go version
go version go1.13.4

containerd -version

containerd github.com/containerd/containerd v1.3.2 ff48f57fc83a8c44cf4ad5d672424a98ba37ded6

uname -a
Linux ubuntu 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/os-release

NAME="Ubuntu"
VERSION="18.04.2 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.2 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

Description

Prometheus is bundled with PLONK (faasd or OpenFaaS on Kubernetes), but with faasd has a private IP for its container. We currently proxy the gateway to port 8080 on the host machine, from the container.

We could do the same for Prometheus so that users can access it via the host IP. This may not be a sensible default, but useful for development/test. The TCP port is 9090 and uses HTTP.

Workaround

Users can also look at the IP in the hosts file in the faasd working directory and then connect to that - with inlets for instance or by using socat to forward the port to the main host IP.

[Feature] add PullPolicy flag / option

Expected Behaviour

Some users prefer to use latest for their images and not to use differing tags, this feature would always pull an image even if it was available locally, in that way, they don't have to change the tag.

Current Behaviour

Possible via:

git init
git add .
git commit -m "Change"
faas-cli up --tag=sha

Or editing the tag

Possible Solution

Add a configuration to the systemd unit file for the flag, and accept it via faas-cli install

Pull code - https://github.com/openfaas/faasd/blob/master/pkg/provider/handlers/deploy.go#L78

Feature

This feature would add support for retrieving logs via the REST API.

Today users can ssh into a faasd machine and run journalctl -u faasd, however, if faasd restarts, the containers become disconnected from the parent process and they no-longer stream output via journalctl.

I don't know how to store / disconnect logs from containerd, but Kubernetes and the CRI interface may show some potential ways of doing this.

There is also a "shim" example from the containerd team, but this is not a fully worked solution. The idea is that a "shim" executable is responsible for starting the container instead of "faasd" itself. The shim executable survives restarts of faasd and can redirect logs to a known location.

An idea may be for us to store logs via syslog or journalctl and then have the API "get/read" logs back from there.

We may need to combine both approaches.

Using the existing DigitalOcean scripts as a basis, extend the bootstrapping to include AWS. This should replicate the existing DO infrastructure exactly, but not replace it . Existing functionality of #67 and #70 MUST be retained

Expected Behaviour

A faasd installation with TLS support is provisioned on AWS when applying the Terraform plan

Current Behaviour

No AWS support currently. Exists in DigitalOcean.

Possible Solution

Add additional aws folder with the scripts in. The existing main.tf file will need amending to allow for choice between DO and AWS

Description

Now that faasd almost has parity with faas-netes/swarm, it can be moved into the openfaas org.

This will result in any artifacts and URLs being under the github.com/openfaas org rather than my personal account and this may encourage more use / testing within the community.

CI, tutorials and blog posts are all likely to break, so a release and update will be required around the same time as the move, or just before.

I'm open to comments/questions/suggestions.

The openfaas org would be picked over the openfaas-incubator given the stability (i.e. the API doesn't need extensive changes) and confusion some people associate with the "incubator" term.

faasd has been listed as an option for certain use-cases on the project documentation to increase awareness - https://docs.openfaas.com/deployment/

Build an installer for all the faasd components

Expected Behaviour

There should be one command to get faasd up on a compatible system, such as Ubuntu 18.04 or Raspberry Pi, that's aware of the architecture and OS, and can bootstrap everything that's required.

Current Behaviour

Many arduous manual steps are required.

This could be a bash script for instance.

Expected Behaviour

Use Go modules instead of dep and remove vendor directory since go modules now handles caching into ~/go/pkg/mod.

The advantage is that it's built-in Go since 1.13 and production on 1.14 ready as stated in https://blog.golang.org/go1.14.

Current Behaviour

Building requires dep, an external application.

Possible Solution

Will submit a PR if the proposal gets +1.

https://github.com/openfaas/faasd/search?q=FunctionNamespace&unscoped_q=FunctionNamespace
the function namespace openfaas-fn is used in fasd . However the resolver does not look like it can handle the function namespace being appended to the function URL (

A user has reported that faas-cli deploy gives back a URL with .openfas-fn appended to the end, and using this URL gives an error about not being able to find the function.

Expected Behaviour

with/without the NS works, or it doesnt ever get sent back to the user on faas-cli use

Current Behaviour

a user has reported getting a url with .openfas-fn appended. This either needs to be handled in faasd resolver/proxy or not returned to a user using faas-cli

Possible Solution

update resolver/stop returning the namespace suffix to the user.

Steps to Reproduce (for bugs)

Context

Your Environment

• OS and architecture:

• Versions:

go version

containerd -version

uname -a

cat /etc/os-release

Expected Behaviour

I want to customise the hostname in the terraform scripts

Current Behaviour

it's always faasd + $DOMAIN

Possible Solution

Extend the scripts - maybe @mehyedes or @Waterdrips would like to take this?

Description

[Feature] Annotation support

We should be able to store annotations from the openfaas deployment JSON.

This could be done in a special hidden label, and is the approach that was taken for faas-swarm

If the instance is restarted using the default user-data script containerd will fail to come up. This can be solved by enabling the service.

Expected Behaviour

Faasd should recover on instance reboot

Current Behaviour

Faasd fails to start with the following error

Feb 23 01:22:55 c3 systemd[1]: Started faasd.
Feb 23 01:22:55 c3 faasd[21554]: 2020/02/23 01:22:55 File exists: "/var/lib/faasd/secrets/basic-auth-password"
Feb 23 01:22:55 c3 faasd[21554]: 2020/02/23 01:22:55 File exists: "/var/lib/faasd/secrets/basic-auth-user"
Feb 23 01:23:05 c3 faasd[21554]: Error: failed to dial "/run/containerd/containerd.sock": context deadline exceeded

Possible Solution

add systemctl enable containerd to user-data

Steps to Reproduce (for bugs)

1. Install using default user-data in the repo
2. validate faasd works
3. reboot the instance
4. systemctl status containerd will show failure

Your Environment

• OS and architecture:
  Ubuntu 18.04 (LXD)

• Versions:

% lxc exec c3 bash
root@c3:~# go version

Command 'go' not found, but can be installed with:

snap install go         # version 1.13.8, or
apt  install golang-go
apt  install gccgo-go 

See 'snap info go' for additional versions.

root@c3:~# 
root@c3:~# containerd -version
containerd github.com/containerd/containerd v1.3.2 ff48f57fc83a8c44cf4ad5d672424a98ba37ded6
root@c3:~# 
root@c3:~# uname -a
Linux c3 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@c3:~# 
root@c3:~# cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.4 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.4 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic