openfaas / faas-swarm Goto Github PK

we should move all our repos to Github Actions because of it's generous free-tier as we're not able to get enough builds out of the free credits that Travis provides.

Expected Behaviour

Build and publish pipelines should work without any issue

Current Behaviour

We're running all our CI builds using Travis CI

Possible Solution

Move to Github Actions

My actions before raising this issue

• [x ] Followed the troubleshooting guide
• [ x] Read/searched the docs
• [ x] Searched past issues

Hi,

I have written a few functions in openfaas. Some of those are not used very frequently. This morning I tried to send a request to a function that was not touched (HTTP request/build/deploy) for a few weeks.

The function never brought up.

Some facts that came from my investigation:

The docker service ps command returns a shutdown state.
docker service inspect returns a MaxAttempts of 5 in the RestartPolicy, which might be related or not.

In the meantime, as we are speaking about local environments, I have shut down my machine every night, which I suppose is affecting the issue one way or another.

Are any of those related? What about the read_timeout/write_timeout settings?

Expected Behaviour

The function to recover as a reaction to the invoke/http request, of course with some expected delay.

Of course, it is all going back to normal if I do a build-deploy again from the faas-cli (new function with the same contents like the old one). But of course I would like this to happen without any manual intervention.

Current Behaviour

The function is not recovering from down state.

Possible Solution

Steps to Reproduce (for bugs)

1. Setup a local function. A plain return {"hello": "world"} would suffice.
2. Leave the function idle for a couple of hours and make sure there is at least a machine restart in the meantime. You may force it by shutting down the docker service which serves the function.
3. Try to reach the function again
4. the function is not waking up

Context

I understand this is a common concern, so I don't think this is a bug, rather a lack of my understanding or documentation.

So my questions are:

• How would you mitigate it? What is most openfaas-y solution for that problem?
• Are timeouts the best setting to amend?
• Is Docker build options a good practice? eg restart policy

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):

  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|

CLI:
 commit:  73004c23e5a4d3fdb7352f953247473477477a64
 version: 0.11.3

Gateway
 uri:     http://127.0.0.1:8080
 version: 0.18.10
 sha:     80b6976c106370a7081b2f8e9099a6ea9638e1f3
 commit:  Update Golang versions to 1.12


Provider
 name:          faas-swarm
 orchestration: swarm
 version:       0.8.2 
 sha:           47988f8ba284678f3eb86eb62f75f72bafeec4d9
Your faas-cli version (0.11.3) may be out of date. Version: 0.12.2 is now available on GitHub.

• Docker version docker version (e.g. Docker 17.0.05 ):

Client: Docker Engine - Community
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        74b1e89
 Built:             Thu Jul 25 21:21:05 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.1
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       74b1e89
  Built:            Thu Jul 25 21:19:41 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Docker Swarm

• Operating System and version (e.g. Linux, Windows, MacOS):
  Linux

• Code example or link to GitHub repo or gist to reproduce problem:
  N/A

• Other diagnostic information / logs from troubleshooting guide
  The service shows no logs.

Thanks,
P.

Per the security announcement https://groups.google.com/forum/#!topic/golang-announce/65QixT3tcmg we should update the docker build layers to at least Go 1.11.13

Possible Solution

Because the docker build layers already use golang:1.11 we should only need to rebuild and tag a new release to ensure that it is using the latest 1.11.13 base image

Related

Update Dockerfile and rebuild/release

openfaas/faas#1291
openfaas/templates#170
openfaas/faas-netes#494
openfaas/nats-queue-worker#66
openfaas/of-watchdog#78
https://github.com/openfaas-incubator/faas-idler/issues/32
openfaas/golang-http-template#28
openfaas-incubator/faas-federation#4
openfaas-incubator/vcenter-connector#27
openfaas-incubator/faas-memory#3
openfaas-incubator/faas-rancher#8

Only Rebuild

#56
openfaas/ingress-operator#10
https://github.com/openfaas-incubator/openfaas-operator/issues/87

This is the function configuration:

provider:
  name: faas
  gateway: http://127.0.0.1:8080

functions:
  kafka-test:
    lang: python
    handler: ./kafka-test
    image: kafka-test
    annotations:
      topic: faas-request
    basic_auth: false

curl -X GET http://127.0.0.1:8080/system/function/kafka-test should return

{  
   "name":"kafka-test",
   "image":"kafka-test:latest",
   "invocationCount":0,
   "replicas":1,
   "envProcess":"python index.py",
   "availableReplicas":1,
   "labels":{  
      "com.openfaas.function":"kafka-test",
      "com.openfaas.uid":"92309200",
      "function":"true"
   },
   "annotations":{  
      "topic":"faas-request"
   }
}

but instead the annotations are prefixed:

 "annotations":{  
      "com.openfaas.annotations.topic":"faas-request"
   }

Possible Solution

The bug is on reader.go#L95.
The prefix is not removed.

Context

Found while testing pull #6
Follows #28

Some integration tests are good to have.

@ewilde Could you please have a look?

Expected Behaviour

Should indicate readiness of function/container via availableReplicas in the /system/function/ endpoint.

This should use techniques from #3 via @ericstoekl

Current Behaviour

This is set to 0 by default.

Possible Solution

Take inspiration from #3 and either create a new piece of code targeted at querying a single service/function or update the existing code to query the additional information optionally and only for a single function.

Expected Behaviour

All functions in the secrets handler for Docker Swarm should work as intended if they are in the code base.

Current Behaviour

The function updateSecret() in the secrets.go handler does not update secrests; it can't because Docker secrets are immutable. An unhelpful status 500 error is thrown when attempting to update a secret via the API gateway using curl -d '{"name":"secret-name","value":"test-edit-i"}' -X POST http://127.0.0.1:8080/system/secrets.

Possible Solution

1. Remove the updateSecret() function completely
2. Handle PUT requests to update secrets with a 405 "Method not allowed" error.

Steps to Reproduce (for bugs)

1. Remove faas-netes or other non-Docker Swarm version of OpenFaaS on local machine.
2. git clone the openfaas/faas repo
3. run ./deploy_stack.sh -n, which installs with basic auth disabled
4. create a secret with curl -d '{"name":"secret-name","value":"test"}' -X POST http://127.0.0.0.1:8080/system/secrets
5. curl -d '{"name":"secret-name","value":"test-edit-i"}' -X POST -v http://127.0.0.1:8080/system/secrets
6. An HTTP/1.1 500 Internal Server Error is returned.

Context

I'm new to Docker and I had no idea that Docker secrets were immutable. Given that, I spent a day trying to figure out why the update part of my test in openfaas/certifier#22 was failing for Docker Swarm installation, but not for faas-netes. The error returned was a 500 error, which made me think it was some logic error on our side.

The code base in faas-swarm wasn't helpful, because the presence of updateSecret() makes it seem like updating was possible.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):
  N/A - I didn't use faas-cli for the secrets CRUD testing.

• Docker version docker version (e.g. Docker 17.0.05 ):
  Docker engine version is 19.03.5.

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Docker Swarm

• Operating System and version (e.g. Linux, Windows, MacOS):
  MacOS Catalina

• Link to your project or a code example to reproduce issue:
  openfaas/certifier#22

With the merge of openfaas/faas-provider#11 we can replace the current FunctionProxy implementation with the standardized proxy implementation from faas-provider. This will ensure consistent proxy behavior among the official providers.

Possible Solution

This requires updating the faas-provider version that is vendored and then separating the function lookup into the BaseURLResolver interface defined in the faas-provider

The CPU limit/reservation feature described in the docs does not work in the swarm cluster.
the test yml file as following:

python.yml

version: 1.0
provider:
  name: openfaas
  gateway: http://harbor.my-domain.com:8080
functions:
  python:
    lang: python3-flask
    handler: ./python
    image: harbor.my-domain.com/openfaas-custom/python:latest
    limits:
      cpu: 1000m
      memory: 1024m
    requests:
      cpu: 100m
      memory: 256m

Current Behaviour

when using faas-cli deploy -f ./python.yml deploy this function, the faas-swarm service shows some error logs as following:

2019/10/18 02:21:08 Error parsing cpu limit: *strconv.NumError
2019/10/18 02:21:08 Error parsing cpu reservations: *strconv.NumError

using docker service inspcet python to check:

...
"Resources": {
                    "Limits": {
                        "MemoryBytes": 1073741824
                    },
                    "Reservations": {
                        "MemoryBytes": 268435456
                    }
                },
...

It shows that CPU limit/reservation does not work.

Expected Behaviour

using faas-cli up or faas-cli deploy deploy the function should set the CPU limit/reservation correctly.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):

CLI:
commit: 5ff1504047756f9ff2e0a10ae64803ab63df470a
version: 0.9.3

Gateway
uri: http://127.0.0.1:8080
version: 0.17.3
sha: d322f109a8379d19b639c003846e721a24ce9dc0
commit: Fix logo location

Provider
name: faas-swarm
orchestration: swarm
version: 0.7.2
sha: ef7d913

• Docker version docker version (e.g. Docker 17.0.05 ):

docker-ce 18.09

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?

Swarm

• Operating System and version (e.g. Linux, Windows, MacOS):

Ubuntu Server 16.04.6

• Link to your project or a code example to reproduce issue:

Unable to deploy a function with an image that is in a private repository (either Docker Hub, or private) when using a tag on the image. private-registry.com/burtonr/test-fn:0.1

Expected Behaviour

Deploy function successful

Current Behaviour

The CLI returns

Unexpected status: 400, message: Invalid registry auth

The log message in faas-swarm:

Error building registry auth configuration: invalid reference format

This is the line that throws the error: https://github.com/openfaas/faas-swarm/blob/master/handlers/deploy.go#L194

Possible Solution

We'd need to parse the dockerImage input to see if there is a tag being used. If so, call the WithTag(), otherwise call the current WithName()

Or, possibly update it to always call the WithTag() function, by setting the tag to latest if it's not supplied. That way there wouldn't be 2 different code paths to follow...

Steps to Reproduce (for bugs)

1. Create a function and update the function.yml image to use a tag: burtonr/test-fn:0.1
2. Push the image to a private registry, Docker Hub or private instance
3. Deploy the function to a Swarm OpenFaaS cluster
4. Observe the CLI response and faas-swarm logs

Context

Unable to use versions of functions from my private registry

Your Environment

• Docker version docker version (e.g. Docker 17.0.05 ):
  Docker 18.03.0-ce
• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Swarm
• Operating System and version (e.g. Linux, Windows, MacOS):
  Ubuntu 17.10 (also tested on Play-With-Docker)
• Link to your project or a code example to reproduce issue:
  it's private 😜

Context

dep is officially being deprecated , the repo is already archived https://github.com/golang/dep

I have already tried the initial update but ran into several issues. It seems like we need to wait for this containerd/containerd#3031 to be resolved, which is currently blocked on this PR containerd/cri#1377 (comment) So progress is being made upstream.

We need to support the /system/info endpoint which has been updated in the latest release of faas-provider

Tasks:

• Update vendored package for https://github.com/openfaas/faas-provider to 0.6
• Add new handler for system info endpoint included in faas-provider package
• Inject build version and SHA into binary at build-time (look at faas-cli as an example of how to do this)
• Add unit test for the HTTP handler

After releasing 0.2.6 a Docker image wasn't pushed by CI - I've done this manually - but we need to look into it. cc @iyovcheva

My actions before raising this issue

• Followed the troubleshooting guide
• Read/searched the docs
• Searched past issues

http://localhost:8080/ui/ return: Get : unsupported protocol scheme ""

faas_gateway log

2019/11/01 02:02:29 HTTP Read Timeout: 5m5s,
2019/11/01 02:02:29 HTTP Write Timeout: 5m5s,
2019/11/01 02:02:29 Binding to external function provider: http://faas-swarm:8080/,
2019/11/01 02:02:29 Async enabled: Using NATS Streaming.,
2019/11/01 02:02:29 Opening connection to nats://nats:4222,
2019/11/01 02:02:29 Connect: nats://nats:4222,
2019/11/01 02:02:30 ExternalAuthHandler: Get : unsupported protocol scheme "",
2019/11/01 02:02:31 ExternalAuthHandler: Get : unsupported protocol scheme "",
2019/11/01 02:02:32 ExternalAuthHandler: Get : unsupported protocol scheme "",
2019/11/01 02:02:32 ExternalAuthHandler: Get : unsupported protocol scheme "",
2019/11/01 02:02:32 ExternalAuthHandler: Get : unsupported protocol scheme "",
2019/11/01 02:02:32 ExternalAuthHandler: Get : unsupported protocol scheme "",
2019/11/01 02:02:32 ExternalAuthHandler: Get : unsupported protocol scheme "",
2019/11/01 02:02:32 ExternalAuthHandler: Get : unsupported protocol scheme "",
2019/11/01 02:02:33 ExternalAuthHandler: Get : unsupported protocol scheme "",

Expected Behaviour

No error

Current Behaviour

Getting error

Steps to Reproduce (for bugs)

1. Deploy stack docker.exe stack deploy -c docker-compose.yml faas
2. Try to access to http://localhost:8080/ui/
3. Got error

Context

Fresh installation return error

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):
  commit: b7a67fe8d6a02aef35caae615ba56333e7337bfe
  version: 0.9.5

• Docker version docker version (e.g. Docker 17.0.05 ): Docker version 19.03.4, build 9013bf5

• Are you using Docker Swarm or Kubernetes (FaaS-netes)? Docker Swarm

• Operating System and version (e.g. Linux, Windows, MacOS): Docker on Windows, faas-cli on linux

• Code example or link to GitHub repo or gist to reproduce problem:

• Other diagnostic information / logs from troubleshooting guide

Next steps

You may join Slack for community support.

Expected Behaviour

Faas-swarm works fine.

Current Behaviour

Faas-swarm crashed soon after starting.

Possible Solution

No solution has been found yet (not familiar with golang).

Steps to Reproduce (for bugs)

1. Follow the instructions on the official website to deploy openfaas on the swarm cluster.
2. Deploy a few of our own business functions.
3. Faas-swarm crashes and restarts repeatedly, the service log is as follows:

2020/06/18 03:07:20 Docker API version: 1.39, 18.09.4
2020/06/18 03:07:20 HTTP Read Timeout: 5m5s
2020/06/18 03:07:20 HTTP Write Timeout: 5m5s
2020/06/18 03:07:20 Basic authentication: true
2020/06/18 03:07:21 ReplicaReader - reading function: 1230-1229-debug
panic: runtime error: slice bounds out of range

goroutine 11 [running]:
github.com/openfaas/faas-swarm/handlers.parseLogStream(0x91f280, 0xc0000be300, 0xc00042e2b6, 0xd, 0xc0003ac2a0, 0x91d100, 0xc0003609c0)
        /go/src/github.com/openfaas/faas-swarm/handlers/logs.go:86 +0x780
created by github.com/openfaas/faas-swarm/handlers.LogRequester.Query
        /go/src/github.com/openfaas/faas-swarm/handlers/logs.go:65 +0x226

Context

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):

  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|

CLI:
 commit:  b7a67fe8d6a02aef35caae615ba56333e7337bfe
 version: 0.9.5

faas-swarm version: 0.8.5

• Docker version docker version (e.g. Docker 17.0.05 ):

Client:
 Version:           18.09.9
 API version:       1.39
 Go version:        go1.11.13
 Git commit:        039a7df9ba
 Built:             Wed Sep  4 16:57:28 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.9
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.11.13
  Git commit:       039a7df
  Built:            Wed Sep  4 16:19:38 2019
  OS/Arch:          linux/amd64
  Experimental:     false

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Docker Swarm
• Operating System and version (e.g. Linux, Windows, MacOS):
  Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-142-generic x86_64)
• Link to your project or a code example to reproduce issue:

Expected Behaviour

The faas-swarm provider should expose the required secrets management APIs as specified in openfaas/faas#807

Possible Solution

Upgrade the faas-provider version to include the changes from openfaas/faas-provider#12 and implement the required secrets handlers

Context

This will help simplify end user deployment of secure functions and simplify documentation such as

• Lab 10 - Advanced feature - Secrets
• OpenFaaS Docs: Secrets

Expected Behaviour

No calls should be possible to the /system/* routes for the providers unless decorated with basic auth. Note that the gateway has more endpoints than the provider and not all endpoints are proxied.

Current Behaviour

The gateway is protected, but not faas-swarm.

This is not a problem for external access since only the gateway is exposed, but internal functions could invoke the endpoints since Swarm gives no way of providing NetworkPolicy.

This change must only become active when basic auth is enabled.

Possible Solution

• Update openfaas/faas gateway to pass credentials to the provider
• Update faas-swarm to bind the same basic auth secrets as the gateway
• Update faas-swarm to validate basic auth using the library added/created for openfaas/faas gateway

Steps to Reproduce (for bugs)

Context

Your Environment

• Docker version docker version (e.g. Docker 17.0.05 ):

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?

• Operating System and version (e.g. Linux, Windows, MacOS):

• Link to your project or a code example to reproduce issue:

Expected Behaviour

The secrets handler for faas-swarm should have tests. Use the httptest package to achieve this.

Current Behaviour

Unavailable.

Possible Solution

You may need to use an interface instead of the Docker client in the handler's make function so that it can be stubbed out with a test double to return the data you need in the test.

See the tests in faas-netes / openfaas-operator for an example of how this was done for other platforms.

Expected Behaviour

Multistage builds should leave as little junk as possible.
Golang alpine 1.11 image fails on cgo dependent tasks.

Current Behaviour

Multistage Docker builds leave the "build" parts in disk as untagged images, ans and using the Fat Golang image in this step produces more than 500Mb.

Possible Solution

Use alpine images.
To use the 11.1 Go Alpine image, it is necessary to add gcc and libc-dev apks to the Dockerfile.

Steps to Reproduce (for bugs)

1. build the Docker Swarm image
2. check the leftovers

Context

This issue prevent unecessary disk and network usage when deploying on Docker Swarm.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):

• Docker version docker version (e.g. Docker 17.0.05 ):
  Docker 18.06.1-ce

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Docker Swarm

• Operating System and version (e.g. Linux, Windows, MacOS):
  Linux 4.18-amd64 (Arch)

• Link to your project or a code example to reproduce issue:
  fass-swarm

Description

Bump up Golang to 1.11 in the Dockerfiles, then test that the build works.

Expected Behaviour

Update to latest faas-provider

Current Behaviour

Release is a little older and lacks /system/namespaces endpoint

This fails to push a new Docker image upon Releasing a new release of the code. Please investigate via the travis logs / .travis.yml file.

Hello, folks,

I'm sorry, but I have to reopen the post.

I use the current version of OpenFaas together with Docker Swarm (multi Node) and a private Docker Registry.

I've read all contributions to this bug, but I still get this message:

> faas-cli deploy -f stack.yml --gateway https://DOMAIN --network proxy --readonly --send-registry-auth

Deploying: SERVICENAME.

Unexpected status: 400, message: Invalid registry auth

Function 'SERVICENAME' failed to deploy with status code: 400

I am successfully logged into my registry and OpenFaas

Originally posted by @JohnOllhorn in #19 (comment)

I have two gateways in two separate docker stacks in the same swarm, each gateway is in its own network. When I deploy functions into the first gateway using faas-cli, they get attached to the network of that gateway. But when I deploy functions into the other gateway, the resulting function services get attached to the network of the first gateway.

Workaround: define a network explicitly using the --network option of faas-cli.

Expected Behaviour

Functions deployed into the second gateway should be attached to the network of the second gateway, and vice versa.

Current Behaviour

Networks:

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
kv2zpddui95l        bem-infra           overlay             swarm
v7hygd71jlcy        bemk_bem            overlay             swarm
mjr1cepesm7y        bemp_bem            overlay             swarm

The bem-infra network is an external network which contains traefik.
The other two networks belong to the two docker stacks, each of which contains a faas gateway.

Faas Deployment: (slightly simplified, there are some more stage-specific env vars)

$ STAGE=p docker stack deploy bemp --compose-file bem/docker-compose.yml
$ STAGE=k docker stack deploy bemk --compose-file bem/docker-compose.yml

Function Deployment:

$ faas deploy -g http://bemp.kvnurs.intra -f bemp-stack.yml
$ faas deploy -g http://bemk.kvnurs.intra -f bemk-stack.yml

Gateway description
The gateway is in network bemk_bem = v7hygd71jlcy:

Service description
The service is in network bemp_bem=mjr1cepesm7y, while it should be in bemk_bem=v7hygd71jlcy:

Possible Solution

The manual deployment function in the faas portal has an option to enter a network during function deployment. Maybe have a network option in stack.yml?

Steps to Reproduce (for bugs)

I have no live example, unfortunately.

Context

I try to create two stages in the same docker swarm.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):
  CLI:
  commit: 87ca614cfe27c4cf2975f7629992c1351b18c2bc
  version: 0.8.8

• Docker version docker version (e.g. Docker 17.0.05 ):
  Client:
  Version: 18.06.1-ce
  API version: 1.38
  Go version: go1.10.7
  Git commit: e68fc7a215d7
  Built: Wed Dec 19 10:23:04 2018
  OS/Arch: linux/amd64
  Experimental: false

Server:
Engine:
Version: 18.06.1-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.7
Git commit: e68fc7a215d7
Built: Tue Aug 21 17:16:31 2018
OS/Arch: linux/amd64
Experimental: false

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Swarm

• Operating System and version (e.g. Linux, Windows, MacOS):
  SuSE SLE12 SP4

• Link to your project or a code example to reproduce issue:
  https://gitlab.la-bw.de/dimag/bestandserhaltungmodul/tree/master/bem_openfaas

Since Swarm is effectively declarative CRUD operations should return 202 Accepted rather than 200 OK since we do not know if things are actually OK that that point. The R of CRUD (retrieve) can return 200 OK.

Context - Issue raised on FaaS repo by Simon @Templum openfaas/faas#693

Expected Behaviour

It should be possible to deploy functions independently into two separate openfaas stacks in the same swarm while avoiding name collisions.

Current Behaviour

I have two openfaas gateways in two different docker swarm openfaas stacks in the same swarm. When I deploy a function into the gateway of the first stack, a function service gets created for that gateway and works fine. But when I deploy the same function (same name) into the other gateway, then the first gateway loses the connection to that function. Redeploying the function into the first gateway does not help. In the gateway logs I see:

2019/04/16 09:20:10 error with upstream request to: , Post http://my-function:8080: dial tcp: lookup my-function on 127.0.0.11:53: no such host
bemk_gateway.1.2jy84fkyzxz9@m1rrzsbem01t    | 2019/04/16 09:20:10 Forwarded [POST] to /function/my-function - [502] - 0.004523 seconds

Ultimately I had to remove all functions and all openfaas stacks and recreate everything from scratch to get it working again.

My understanding is that function services do not become part of a stack. The gateway finds its function services by means of a label. Here is my function in faas-cli describe:

Name:                my-function                                            
Status:              Ready                                                     
Replicas:            1                                                         
Available replicas:  1                                                         
Invocations:         0                                                         
Image:               bem-docker-registry.kvnurs.intra:443/my-function:latest
Function process:                                                              
URL:                 http://bemk.kvnurs.intra/function/my-function          
Async URL:           http://bemk.kvnurs.intra/async-function/my-function    
Labels:              function : true                                           
                     com.openfaas.function : my-function

I assume the gateway finds its functions using the com.openfaas.function label. On deployment the gateway apparently attaches the function to its own network.
Now, when the gateway in the second stack deploys the same function, it seems to disconnect the function from its current network and attaches it to its own network (and probably does other things which cause more confusion).

Possible Solution

A solution must allow the function to be a separate entity for docker if it is deployed into a different stack. The function must become a separate service for each stack, which scales independently etc. The only way to achieve that is a different service name, I am not aware that service labeling alone can help us here.

As long as the service has the same name in both stacks, it is probably not possible to achieve that.

Suggestion:
The openfaas yml format could introduce a name field below each function key whose value supports env variable substitution. The gateway uses the service key to build the service url and the name field to create the service name in docker.
Docker has done similar things with name fields for configs and volumes, so maybe that is not so far-fetched after all.

Workaround:
Create separate stack.yml files with separate service names prefixed for each stack and let callers use the appropriate url for each stack, i.e. http://localhost:8080/functions/develop_my-function.

Steps to Reproduce

1. deploy the openfaas stack twice under two different stack names. (To make this possible, let the gateway of the second stack run under a different port)
2. use faas-cli to deploy a function into the gateway of the first stack. Check that it works properly
3. deploy the same function into the gateway of the second stack

Result:

• faas-cli list shows that both stacks know the function, fass-cli describe even claims that the function is ready in both stacks
• the function does not work, rather you get a 502
• redeploying the function into the gateway of the first stack does not fix it. I had to delete all functions and all stacks and deploy a new stack from scratch to get it working again with a single stack.

Context

In my scenario we have used swarm stacks for staging. Each swarm stack is a different stage (stages as in development - acceptance test etc. where placement constraints are used to distribute the containers to separate nodes depending on the stage).

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):

 commit:  87ca614cfe27c4cf2975f7629992c1351b18c2bc
 version: 0.8.8

• Docker version docker version (e.g. Docker 17.0.05 ):

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.7
 Git commit:        e68fc7a215d7
 Built:             Wed Dec 19 10:23:04 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.7
  Git commit:       e68fc7a215d7
  Built:            Tue Aug 21 17:16:31 2018
  OS/Arch:          linux/amd64
  Experimental:     false

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Swarm

• Operating System and version (e.g. Linux, Windows, MacOS):
  Linux Suse SLE12 sp 4

• Link to your project or a code example to reproduce issue:
  n/a yet

Expected Behaviour

Be able to connect to a Docker API endpoint with TLS enabled.

Current Behaviour

I have a openfaas/faas-swarm service with the following environment variables set.

DOCKER_API_VERSION: 1.39
DOCKER_HOST: tcp://10.57.21.68:2376
DOCKER_TLS: 1

I'm expecting faas-swarm to connect to the Docker API endpoint with TLS enabled. But, the logs show it's not.

2019/06/26 17:35:46 Error with Docker server: Get http://10.57.21.68:2376/v1.39/version: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02".
* Are you trying to connect to a TLS-enabled daemon without TLS?

Possible Solution

Unknown.

Steps to Reproduce (for bugs)

Here's a snippet of my service definition for faas-swarm.

  faas-swarm:
    image: openfaas/faas-swarm:0.6.2
    environment:
      read_timeout: 5m
      write_timeout: 5m
      basic_auth: "true"
      secret_mount_path: /run/secrets
      DOCKER_API_VERSION: 1.39
      DOCKER_HOST: tcp://10.57.21.68:2376
      DOCKER_TLS: 1

Context

I want to be able to connect to a remote Docker swarm manager endpoint that has TLS enabled.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ): N/A

• Docker version docker version (e.g. Docker 17.0.05 ): 18.09.6

• Are you using Docker Swarm or Kubernetes (FaaS-netes)? Swarm

• Operating System and version (e.g. Linux, Windows, MacOS): Linux

• Link to your project or a code example to reproduce issue: N/A