openfaas / faas Goto Github PK

Kubernetes has a convention of a healthz endpoint on port 10254.

• Introduce this for the watchdog / gateway etc.

London - 14th June
Title: How Serverless Functions will XLR8 your Cloud with Docker
Slot: 20 min
Audience: seats 100

Abstract:

This talk gives an overview of Serverless - a new architecture for building small, discrete and reusable chunks of code which when combined are more than the sum of their parts. You will see demos of integrations with the Amazon Alexa voice assistant, Twitter and Slack. The baked-in metrics give operational oversight and allows your functions to scale to demand - automatically.

Functions as a Service (FaaS) by Alex Ellis is a framework for building serverless functions on Docker with first class support for metrics. Any code can be packaged as a function enabling you to consume a range of web events without repetitive boilerplate coding.

This way cool, and thanks for posting this project!

I ran the quickstart, and again on my local machine, however I wasn't able to successfully bring the UI portal up.

1. Cloned mater branch
   2 ) docker swarm init --advertise-addr=$(ifconfig eth0| grep 'inet addr:'| cut -d: -f2 | awk '{ print $1}') && git clone https://github.com/alexellis/faas && cd faas && ./deploy_stack.sh && docker service ls
2. used curl to verify the stack was consumer web events
3. checked prom to which came up without issues
4. checked AlertManager also no issues.
5. tried http://localhost:8080 and I can only see a white screen, even though I can post events.

Curious if you have any tips to get to the UX screen.
TIA!

Is it possible to keep a function running? The initialization of my function takes a long time so I have a delay in every call I make. It would be nice if my function could stay open and read every new line that is coming in via STDIN.

Expected Behaviour

Now that the Gateway can be load-balanced an invocation count should cover the count across all of the gateways.

Current Behaviour

For Swarm it shows the current gateway instance since we're reading the local counter

For Kubernetes it shows as empty

Possible Solution

Query the Prometheus API from the gateway:

PromQL example:

gateway_function_invocation_total{}

Concerns:

• creates a circular dependency since the gateway is a scrape target

• scrape interval is around 5-15s meaning we won't see the invocation count increase live.

• this data needs to be overlaid on top of the "list functions" response from Swarm or the external gateway - See: faasHandlers.ListFunctions in server.go for the FaaS gateway

Your Environment

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

Both

Expected Behaviour

With Lambda a modified Flask library can be used called Zappa to handle single requests.

CC @JockDaRock

Current Behaviour

This appears to be incompatible, but..

Possible Solution

A CGI handler works in its place and lets you retain template functionality and views etc.

Improve logging for functions during error conditions via @thejibz

Within watchdog binary:

The exec of process:

• results in non-zero exit code
• finds output in stderr and nothing in stdout
• gets output in stderr and stdout

#10 (comment)

Also review whether panic is the correct behaviour for failure of exec.

If there is a mix of resolved/firing statuses for > 1 function both auto-scale.

Expected Behavior

The function at a reasonable rate should not scale. The function under pressure should

Current Behavior

The previous function that had an alert scales with the new function under load

Possible Solution

Check the message for more detail - specifically to see if each function has an individual status of OK/firing.

Steps to Reproduce (for bugs)

Force NodeInfo sample to scale - let it back off - then force EchoIt to scale. Both will scale together even though they shouldn't.

DIND Docker in Docker can be used to deploy FaaS, run some basic tests and get a confidence level RE: PRs/changes.

Initial version of this would deploy built-in stack and test echo function for example.

Help wanted on this (re: time)

• Healthcheck useful for Swarm
• Checks for readiness / health of watchdog within container

Write a lock file in /tmp/ on start so that we know the function can accept HTTP connections.

Initial areas for security strategy. Implementation needs to be easy to use when deployed locally or in development environment.

UI

Static Angular UI tester visible when deployed

Suggestion - HTTPs / basic auth and cookie. Minimum initial version could have a single admin account.

System API

Endpoints: deploy function / delete function / get a list of functions

Approach needs to be consumed by the UI and by an optional CLI.

Functions API

I.e. /function/function_name [POST]

This can be split into two use-cases:

For the functions expecting webhooks, it's rare that I've seen anything here - sometimes a digest of the message from the remote party. Mainly just a HTTP POST with a body to your endpoint.

For endpoints not receiving webhooks from third-parties, but being used as part of a chain of functions etc - maybe here it makes sense to add some kind of header/bearer token / JWT.

Related

• Rate limiting
• IP black/whitelisting
• Account lock-out for bad login attempts
• Account reset (via? email?)
• Is persistent storage needed for any of the above?

It would be great to have a basic security on admin ui and / or function call

Expected Behavior

The goal would be to provide an API token to enble basic security on gateway UI access and function call.

Current Behavior

There is no security to access gateway UI or call a function. Anybody that have access to ui can add a function.

Possible Solution

Add an API key for each call to gateway UI to secure access.
Add an generated API key for each function in order to secure access to them

see https://foobar123.com/serverless-security-594942b496ec

Ease the use and pipelining of FaaS functions within a shell script.

Expected Behavior

Pipe from and to FaaS function just as with local utils.

Current Behavior

We can curl http://faas... | and | curl -X post -d '$(</dev/stdin)' http://faas but it feels quite clumsy.
Maybe a little wrapper script or Go app could help, to pipe from/to a single faas-exec without extraneous switches.

Possible Solution

cat input.txt | faas-exec func1 | faas-exec -extraparam func2
cat input.json | faas-exec func1 | faas-exec func2 (recognizes json and sets header)

Then, chaining FaaS would just be as simple as using core shell utils.

Context

Trying to demo the ease of use of FaaS by running complex stacks (NLP) within Docker containers, but need some transform steps on data before and after. Need an easy way to chain local and FaaS processes.

A logo will be useful for promoting project. Currently underway with designer.

At the same time a new project name could be useful. FaaS sounds a lot like "fast" which was confusing in the US.

Long running functions (8+ seconds) return with empty responses.

Expected Behavior

STDOUT should be returned in the response body.

Current Behavior

The response body is empty.

Steps to Reproduce

Deploy faas.
Create the following files:

func.yml

version: '3.1'

services:
  test:
    image: functions/alpine
    networks: [ func_functions ]
    labels:
      function: 'true'
    environment:
      read_timeout: 60
      write_timeout: 60
      fprocess: 'sh /root/func.sh'
    volumes:
    -  .:/root
networks:
  func_functions:
    external: true

func.sh

DELAY=`cat -`
echo hi, sleeping for $DELAY
sleep $DELAY
echo done sleeping, bye!

This function takes a number as input and sleeps for that duration before responding.
Let's deploy it:

> docker deploy -c func.yml issue
> docker service logs -f issue_test

And curl the service to run for different lengths:

> time curl localhost:8089/function/issue_test -XPOST -d6
hi, sleeping for 6
done sleeping, bye!

real    0m6.013s
user    0m0.004s
sys     0m0.001s

> time curl localhost:8089/function/issue_test -XPOST -d7
hi, sleeping for 7
done sleeping, bye!

real    0m7.013s
user    0m0.000s
sys     0m0.006s

> time curl localhost:8089/function/issue_test -XPOST -d8
curl: (52) Empty reply from server

real    0m8.013s
user    0m0.000s
sys     0m0.005s

> time curl localhost:8089/function/issue_test -XPOST -d9
curl: (52) Empty reply from server

real    0m9.013s
user    0m0.002s
sys     0m0.003s

The test cases for 8 and 9 seconds still return a response, but the response is empty.

Context

@cgpuglie and I are trying to run a web-scraper with nightmare-js as a faas function.
The runtime is variable, but typically longer than 8 seconds.

Your Environment

> docker version
Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Thu May  4 22:10:29 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.05.0-ce
 API version:  1.29 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Thu May  4 22:10:29 2017
 OS/Arch:      linux/amd64
 Experimental: true

Bump to Golang 1.8.x across all repos

This includes faas, faas-cli and faas-netes.

All existing tests should pass including functional test.

This will also need an ARMHF Golang Dockerfile.

I currently haven't tried FaaS yet, but will do asap. I have one question though, something I couldn't make up from the documentation.

Is it currently possible to create pipes? Thus, to link the STDOUT from one function to the STDIN of another function? Would something like this work?

mkfifo fifo
./process1 argument1 < fifo | ./process2 argument1 > fifo

http://stackoverflow.com/questions/5129276/how-to-redirect-stdout-of-2nd-process-back-to-stdin-of-1st-process

Thanks,
Bas

The benchmark tools at https://github.com/networknt/microservices-framework-benchmark provides a common "microservices" framework for testing and characterizing performance across systems; it would be useful to set something up for this.

The benchmark provided is a simple "Hello world" fetch, which is simple to implement.

Expected Behavior

Performance of FaaS is well-characterized.

Current Behavior

Performance of FaaS seems to be good, but there aren't numbers.

Possible Solution

Do some simple load testing, and characterize performance, prior to running a benchmark.

Context

The "microservices" list has a lot of interesting projects in it which is worthwhile to review in any case.

Hard timeouts should be available for functions to prevent them running beyond desired duration.

Expected Behavior

I.e. with a hard_timeout of 3 seconds, the process/request should be killed with appropriate HTTP error code after going beyond 3000 ms.

Current Behavior

Read/Write timeouts are set at the HTTP gateway.

Possible Solution

Go routine / timer

A CLI that would allow FaaS to build / deploy functions without using curl / docker CLI directly.

Possible Solution

Some progress started at:

https://github.com/alexellis/faas-cli

From Alibaba employee - Quai.io is banned in China, change to Hub reference.

Expected Behavior

If there are multiple gateways in the same swarm, it should be possible to configure the gateways to pick up specific sets of functions, perhaps by labels. Otherwise, each gateway picks up all function services in the swarm.

Current Behavior

Function services are currently denoted by the presence of a function label on the service. Gateways automatically pick up all services with this label.

Possible Solution

As an example, Traefik can be configured with constraints for which Traefik configured services it handles. Only services that match the constraint (via tags on labels) will be handled by the Traefik instance. This enables multiple instances of Traefik to be deployed on a swarm, each handling a different set of services.

Context

I'm trying out FaaS in a project. The repo branches for this project are automatically built and deployed on a Docker swarm for review as part of a CI/CD process. The FaaS gateways from the deployments are picking up the functions from all the deployments, not just the specific branch. There doesn't seem to be a way to limit each gateway to the services for a specific deployment.

Your Environment

• Docker version docker version (e.g. Docker 17.0.03 ): 17.0.04
• Operating System and version (e.g. Linux, Windows, MacOS): Development on macOS. CI/CD deployments on RHEL 7.3.
• Link to your project: Not available (internal).

Expected Behavior

I expect to be able to add a new function to a running installation without relaunching all of them, but I get an ambiguous error from the docker command I try. Instead I need rerun deploy_stack to relaunch everything.

Current Behavior

Edwards-Air:oblique emv$ docker run --label "function:true" --network func_functions --env "fprocess:oblique" vielmetti/faas-oblique
docker: Error response from daemon: Could not attach to network func_functions: rpc error: code = 7 desc = network func_functions not manually attachable.
ERRO[0000] error getting events from daemon: net/http: request canceled 

I expected to be able to add a function to the func_functions network, but was rejected. Is this a Docker issue? Did I get the attach command wrong?

Context

This might just be a documentation issue, as this was my first go-around at trying this.

My function is in the Docker container vielmetti/faas-oblique, and it implements Brian Eno's "Oblique Strategies" card deck by emitting a random card from that deck as a line of text.

Your Environment

• Operating System and version:
  Docker Version 17.03.1-ce-rc1-mac3 (15924)
  Channel: edge
  1795b358d5

Watchdog not reading config overrides when set to false

Research / proof of concept item.

Gateway

Using kubeadm or similar - FaaS should be able to deploy on a Kubernetes cluster using the API server to schedule and scale services.

• Does the auto-scaling component need to be refactored into its own process/container?

• via @errm - should API gateway create / apply new functions or should this be done via kubelet?

Alex - symmetric design would have the gateway create services on Swarm or Kubernetes via API

• Ingress controller may be needed such as traefik unless the gateway can perform that role.

Other notes:

Kubernetes also supports ARMv7 (Raspberry Pi 2/3) but not the Zero/Pi 1 due to memory constraints.

Function Watchdog

The function watchdog can already be scheduled as a service to a Kubernetes cluster without changes.

Supporting software

• Prometheus and AlertManager can also be scheduled on K8s without changes

I'd like to see a function container that was not restarted upon every request, preferably something that would accept HTTP or that could talk to a message queue (Redis, MQTT, etc.)

Design and run complex flows / State machines from FaaS functions.

Expected Behavior

The idea is similar to amazon step functions and states language.
See https://aws.amazon.com/fr/blogs/aws/new-aws-step-functions-build-distributed-applications-using-visual-workflows/
We could use a visual editor to chain functions.

Possible Solution

I'm willing to explore the node-red road : the blocks are highly configurable, do have properties, and the resulting flow can be saved as a Json file.
The node red editor is stable and used in several projects.
Functions are blocks, We'll need some structure control as well (parallelism, conditions, retries)

Context

I'd like to reduce friction when adopting FaaS, and allow non dev to build complex data flows.

Those are just some thoughts right now, but I'll try to demo something.

I'm simply suggesting to add this function. I use it to store passwords (while ensuring they are never plain-text) in our local documents. I used the container Alpine and installed openssh.

Just replace the master password 'FancyPasswordHere' with yours.

1) fct_crypt

#### ENCRYPT
#Generate a 32 characters password
STEP1=$(docker run --rm alpine sh -c \
"cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1")
#Show the password
echo "$STEP1" && echo
#Encrypt the pass
STEP2=$(echo "$STEP1" | openssl enc -aes-256-cbc -a -k "FancyPasswordHere")
STEP1="null"
#Create a variable so it will be quick to copy-paste it later
STEP3="THIS_VAR='$STEP2'"
#Show the final string to copy in your files
echo "$STEP3" && echo
# Copy it in the clipboard (mac)
echo $STEP3 | pbcopy
echo "Just paste your encrypted password into your files."

2) fct_decrypt

Copy-paste back the output of the previous command. ie:
THIS_VAR='U2FsdGVkX19YVGj32Z0lb1YlJbD2S3/wa9GQAliwOwPWgvSXHQ1gLnkgNovzMdtd pk7atELI8iWVAql65rmMQQ==', then run

#### DECRYPT
echo "Copy-paste back the output of the previous command. Then run:"
echo "$THIS_VAR" | openssl enc -aes-256-cbc -d -a -k "FancyPasswordHere"

Cheers!
https://twitter.com/askpascalandy

The name of the FaaS project will transition to OpenFaaS. This issue is going to track the progress and list areas needing to change.

Areas to cover:

• Repo names may stay the same and move to an organization.
• New website www.openfaas.com - live with HTTPS, but without content.
• additional pages to be added for features etc.
• Utility download script cli.openfaas.com
• Twitter handle -> @open_faas
• GitHub repo -> https://github.com/openfaas
• Import paths for GitHub
• Add logo to README / GitHub pages site.
• Change FaaS Gateway to "OpenFaaS Gateway" in UI

Anything else?

Asynchronous processing should be possible for long-running functions.

Must have:

• Work can be accepted through a new route or a Header

/async/function/<function_name>

Or via Header:

X-etc: async

• Work is accepted immediately and a 202 Accepted is returned. This should be handed off to a queue.

• One or more (scaleable) asynchronous workers read from a queue and call functions

• Should dequeue item atomically

• Upon failure another worker should pick up the item

• For initial version - HTTP should be used by worker to call function just like the gateway does. Timeout will depend on the configuration of the function.

• Prometheus metrics to be logged for work queued/processed/outstanding

Could have:

• Watchdog configuration to state whether async/sync is supported
• Validation in gateway for invocation method
• Retry logic on failure

Nice to have:

• Additional logging beyond docker service logs
• Callback URL could be specified via header or query-string - this could be called by the framework upon completion

Notes:

Have looked into Kafka - design looks overly complex for task at hand.
NATS queuing is not resilient - but NATS Streaming may be suitable.

To resolve #94 or provide temporary work-around.

Expected Behavior

The API Gateway has hard-coded 8-second timeout, this should be configurable. Most people will want this to be shorter - some longer.

Current Behavior

8-seconds is the max duration

Possible Solution

Introduce environmental configuration to match that of the watchdog's configuration options.

https://github.com/alexellis/faas/blob/master/watchdog/readconfig.go

Steps to Reproduce (for bugs)

See #94 or set fprocess to sleep 10.

cc/ @stealthybox

It isn't clear to me how to set the Content-Type on an individual function, particularly run via the fwatchdog.

Expected Behavior

I should be able to write HTTP headers as part of the output of the program (like cgi-bin):

Content-Type: text/plain


hello world

Or specify it in the docker-compose:

   hello:
        image: functions/alpine:latest
        labels:
            function: "true"
        depends_on:
            - gateway
        networks:
            - functions
        environment:
            fprocess: "echo hello world"
            content_type: "text/plain"
            no_proxy: "gateway"
            https_proxy: $https_proxy

Current Behavior

Content-Type appears to be unset when using fwatchdog.

Possible Solution

1. static content_type in docker-compose
2. override_headers: "true"/"false" would allow the script to indicate http headers (via \n\n above)
3. headers_stderr: "true"/"false" override headers written to stderr

Happy to build something for PR if there is a desired direction.

When using our own private docker registry, we need the swarm cluster to be able to pull images (functions) from it.

Expected Behavior

When a new function service is created in Swarm, images from a private registry should be correctly pulled provided the registry credentials are available somewhere.

Current Behavior

Images cannot be pulled by Swarm workers.

Possible Solution

We can rely on the mechanism provided by the --with-registry-auth flag in the docker stack command, which forwards the registry credentials to all swarm nodes.
When creating a service using the golang Docker sdk, we can pass the appropriate encoded registry auth (base64 encoding of the json string representation).
I have a proposal there, based on environment variables configuration: sebgl@e7d2deb
If you think that makes sense I can open a pull request.

Steps to Reproduce (for bugs)

1. Push function image to a private Docker registry
2. Try to invoke the function with FaaS (making sure the docker image is not already available locally on swarm nodes)

Context

We would like to use FaaS with private Docker registries (not only hub.docker.com but any registry).

Your Environment

• Docker version: Docker 17.05.0-ce

The gateway could be a bottleneck in very high workloads. It should be able to scale.

Current Behavior

Prometheus scraping would break

Possible Solution

Add to prometheus.yml config:

  - job_name: "gateway"
    scrape_interval: 5s
    dns_sd_configs:
      - names: ['tasks.gateway']
        port: 8080
        type: A
        refresh_interval: 5s

Expected Behavior

Attempt to port gateway and/or function watchdog over to Windows containers.

Possible Solution

Easiest way to try this may be to start by porting the watchdog component over to Windows containers and then attaching it to the existing Linux API Gateway.

Help wanted: yes!

Serverless Inc framework provides a CLI / abstraction to public cloud, but they do not appear to have any Docker or Swarm backed providers.

Related: #58

Help wanted from community.

Research:

Run a spike / PoC to integrate with serverless project:

Repo & skeleton created:

• https://github.com/alexellis/serverless-faas

Goals:

• Identify missing endpoints/API in FaaS and back-fill
• Explore pros/cons of maintaining Serverless Inc Plugin over FaaS' own CLI
• Understand security / api/secret key etc requirements for self-hosted vs managed (cloud) function service.

Bind mounting config files for Prometheus and AlertManager means it's hard to remotely deploy with docker-machine etc. From: @timhaak

Possible Solution

Build new images with config added already under functions repo on the Hub. Ideally via auto-build.

I have attempted to manually start and run the stack without using the playground with a few issues when accessing the web ui.

Steps to Reproduce (for bugs)

I built and started the stack with the shell scripts, then I attempted to load http://localhost:8080 and got forever-loading empty request.

1. ./build.sh
2. ./deploy_stack.sh

Deploying stack
Creating network func_functions
Creating service func_gateway
Creating service func_alertmanager
Creating service func_nodeinfo
Creating service func_markdown
Creating service func_decodebase64
Creating service func_wordcount
Creating service func_hubstats
Creating service func_prometheus
Creating service func_echoit
Creating service func_base64
Creating service func_webhookstash

• curl localhost:8080/function/func_markdown/ -d "## Testing"
• curl: (56) Recv failure: Connection reset by peer

I inspected the docker network and got the ip for the gateway container, and accessed it via http://<containerid>:8080. I got a white page with just this text: Select a function..

I also manually ran docker-compose build docker-compose up docker-compose down to see if raw compose was a possible solution. I checked but didn't see a particular version of docker that is required.

Am I doing something entirely wrong, or is there a step for setting up the network that I need to do first?
I read all the md files in the repo, your blog post referencing faas, and some of the linked gists without finding a particular solution.

Your Environment

• Docker version version 17.06.0-ce, build 02c1d87

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

Debian Linux 4.9.0-3-amd64

when to execute

docker stack deploy -c docker-compose.yml func

Expected Behavior

pass

Current Behavior

ERROR: yaml.scanner.ScannerError: while scanning for the next token
found character '\t' that cannot start any token
in "./docker-compose.yml", line 106, column 22

Possible Solution

#25

Steps to Reproduce (for bugs)

1. git clone faas && cd faas && docker stack deploy -c docker-compose.yml func

Context

Your Environment

• Version used: 17.03.0-ce
• Environment name and version (e.g. nginx 1.9.1):
• Server type and version:
• Operating System and version:
• Link to your project:

Expected Behavior

Auto-scaling without any drop in performance

Current Behavior

Lack of health check (only in arm examples) means that the performance drops and could cause oscillation between replica counts.

Possible Solution

• Just need to add HEALTCHECK CMD as per 64-bit examples.
• Release new version of Watchdog for ARMHF

Run performance tests with VIP resolution vs IPVS.

Context

• Monitor conntrack under high connection load > 10k requests
• Observe whether replicas are brought into round-robin before they are "ready"

It would be great to get this working on ARMv8.

Expected Behavior

The goal would be to provide a Dockerfile that enables FaaS on ARMv8 machines, specifically getting the watchdog process running.

Current Behavior

The biggest challenge I've identified is finding a compact base container that provides a current version of Go to build and run the worker. The aarch64/ubuntu-golang container is more than a year old, for example. aarch64/ubuntu-golang#4

Possible Solution

Work upstream to get a good aarch64/golang base image, and this becomes nearly trivial.

Context

Looking to port this environment to the Packet 2A 96-core ARM servers.

I did a number of Moby Mingles at DockerCon on the topic of Serverless. During those mingles, I showed people FaaS. The following are some of the questions that came up during discussions (they're not necessarily FaaS-specific).

• How does the watchdog work?
• Do I have to have a replica of each function (what if I have thousands)?
  • What about management/discovery of all those functions?
• How do I register a new function?
• Does it work with k8s?

I'm able to stash (via func_webhookstash) a small text file, but when attempting a larger file (1.8M) the command simply hangs.

Expected Behavior

I expect no behavior difference, regardless of file size/type.

Or I expect a meaningful error.

Current Behavior

The larger upload hangs indefinitely.

I do see the gateway forwarding to webhookstash:

docker logs -f func_gateway.1.mazbcz33vjo5lhkviyj2y5kb3  

Resolving: 'func_webhookstash'
[1490657353] Forwarding request [application/x-www-form-urlencoded] to: http://10.0.0.20:8080/

However, I see no further logging information.

Steps to Reproduce (for bugs)

dev % ls -al hello.txt IMG_0733.JPG
-rw-r--r-- 1 nick nick      12 Mar 27 16:22 hello.txt
-rw-r--r-- 1 nick nick 1815980 Mar 27 13:44 IMG_0733.JPG

dev % cat hello.txt | curl -X POST http://localhost:8080/function/func_webhookstash --data-binary @-  
Stashing request

dev % cat IMG_0733.JPG | curl -X POST http://localhost:8080/function/func_webhookstash --data-binary @-

hangs indefinitely

Environment

• Docker version 17.03.0-ce, build 60ccb22
• Linux dev 4.8.0-41-generic #44-Ubuntu SMP Fri Mar 3 15:27:17 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
• Ubuntu 16.10

Expected Behavior

The response should be a JSON-formatted version of the 'text' body.

Current Behavior

The response is currently null or '' for all entries.

Possible Solution

Convert the textual response to JSON.

Steps to Reproduce (for bugs)

1. Clone repository on Playing With Docker.
2. Visit the UI page.
3. Select func_nodeinfo
4. Select JSON response.
5. Note null response, test again with Text and observe non-null response.

Can be reproduced with any of the functions that give an output.

Context

Just found it playing around with the default FaaS

Your Environment

• Playing with Docker defaults.

(tagging @developius)

Hi,

I just want to confirm Docker file for https://hub.docker.com/r/functions/alpine/.
Can you git-add this file into repo too?

Thank you for exciting project!!

Item - Research into running FaaS with Azure CNI as a back-end

This may be via the Azure API or through the ACI Kubernetes Connector.

ACI:

https://azure.microsoft.com/en-us/blog/announcing-azure-container-instances/

Kubernetes connector:

https://github.com/Azure/aci-connector-k8s

Container instances have granular billing, public or private IPs and can be deployed to multiple regions easily. No backing VM is necessary either.

Expected Behaviour

Watchdog should timeout after 5 seconds (default) or the configured amount of seconds.

Current Behaviour

Resulting timeout values are very large.
It's not possible to configure small values.
This also affects the default.

Possible Solution

Remove the extra arithmetic in main.go.

Context

This doesn't look intentional.
I'm not sure what the repercussions are.

I discovered this when copying the timeout configurations over to the Gateway httpServer.

Expected Behaviour

Expected faas-cli to successfully build the function with:

faas-cli -action build -f ./urlping.yaml

Current Behaviour

.
.
.
cp - ./template/python/requirements.txt ./build/url_ping/requirements.txt
cp - ./template/python/function/handler.py ./build/url_ping/function/handler.py
2017/07/10 10:51:14 readdirent: invalid argument

Possible Solution

Steps to Reproduce (for bugs)

1. create urlping.yaml as described in README.md
2. create ./sample/url_ping as described in README.md
3. execute faas-cli -action build -f ./urlping.yaml

Context

Trying the sample code to get FAAS working in my environment

Your Environment

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

docker version
Client:
Version: 17.06.0-ce
API version: 1.30
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 21:31:53 2017
OS/Arch: darwin/amd64

Server:
Version: 17.06.0-ce
API version: 1.30 (minimum version 1.12)
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 21:51:55 2017
OS/Arch: linux/amd64
Experimental: true

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

• Link to your project:
  N/A

Expected Behaviour

Deploying a function on a mixed-OS cluster should be possible - where a Windows container is scheduled correctly.

Current Behaviour

The task will be scheduled randomly - possibly on a Linux host.

Possible Solution

Add a default constraint to Linux and allow this to be overridden in the deploy function endpoint. A change to the CLI may also make sense later down the line.

Checkpoints:

• encompasses the RESTFul schema

Schema https://github.com/alexellis/faas/blob/master/gateway/requests/requests.go#L7

• Includes an update to the swagger API

• Covers both Kubernetes and Swarm