Giter VIP home page Giter VIP logo

faas-nomad's Introduction

Build Status Docker Repository on Quay OpenFaaS Maintainability Test Coverage

OpenFaaS - Nomad Provider

This repository contains the OpenFaaS provider for the Nomad scheduler. OpenFaaS allows you to run your private functions as a service. Functions are packaged in Docker Containers which enables you to work in any language and also interact with any software which can also be installed in the container.

OpenFaaS Architecture

For the simplest installation, only two containers need to run on the Nomad cluster:

  1. OpenFaaS Gateway
  2. OpenFaaS Nomad provider However for OpenFaaS to automatically scale your function based on inbound requests and to be able to gather metrics from the Nomad provider two additional containers are optionally run.
  3. Prometheus DB
  4. StatsD server for Prometheus
  5. Grafana for querying Prometheus data

OpenFaaS Gateway

The gateway provides a common API which is used by the command line of for deploying functions. In addition to this it also hosts a Prometheus metrics endpoint which is used to provide operational metrics. The gateway does not itself interact with the Nomad cluster instead it delegates all requests to the Nomad provider.

Nomad provider

The Nomad provider is responsible for performing any actions on the Nomad server such as deploying new functions or scaling functions. Also it also acts as a function proxy. Metrics such as execution duration and other information are emitted by the proxy and captured by the StatsD server. Prometheus regularly collects this information from the StatsD server and stores it as time series data.

OpenFaaS Functions

The functions performing the work on OpenFaaS are packaged as Docker images. When running on the cluster these functions do not provide any external interface; instead, interactions are performed through the Nomad provider. When a function is deployed, it is registered with Consul's service catalog. The provider uses this service catalog for service discovery to be able to locate and call the downstream function.

Starting a local Nomad / Consul environment

First, ensure that you have a recent version of Nomad and Consul installed, the latest versions can be found at:
Consul Versions | HashiCorp Releases
Nomad Versions | HashiCorp Releases

Make sure you download the correct architecture for your machine, binaries are available for most platforms, Mac, Windows, Linux, Arm, etc.

To get things up and running quickly you can run the bash script located in the root of this repository.

$ source ./startNomad.sh                                                                                                                                              
Discovered IP Address: 192.168.1.113                                                                                                                           
Starting Consul, redirecting logs to /Users/nicj/log/consul.log                                                                                                
Starting Nomad, redirecting logs to /Users/nicj/log/nomad.log                                                                                                  
NOMAD Running 

The startup script will set the advertised address to your primary local IP address and run both Nomad and Consul in the background redirecting the logs to your home folder.

Using Vagrant for Local Development

Vagrant is a tool for provisioning dev environments. The Vagrantfile governs the Vagrant configuration:

  1. Install Vagrant via download links or package manager
  2. Install VirtualBox via download links or preferred hypervisor of your choice (vagrant plugins may be required). VMWare Fusion is supported.
  3. vagrant up (default VirtualBox) or vagrant up --provider vmware_fusion

The provisioners install Docker, Nomad, Consul, and Vault (via Saltstack) then launch OpenFaaS components with Nomad. If successful, the following services will be available over the private network (192.168.50.2):

  • Nomad (v0.8.4) 192.168.50.2:4646
  • Consul (v1.2.0) 192.168.50.2:8500
  • Vault (v0.9.6) 192.168.50.2:8200
  • FaaS Gateway (0.9.14) 192.168.50.2:8080

This setup is intended to streamline local development of the faas-nomad provider with a more complete setup of the hashicorp ecosystem. Therefore, it is assumed that the faas-nomad source code is located on your workstation, and or is configured to listen on 0.0.0.0:8080 when debugging/running the Go process.

Starting a remote Nomad / Consul environment

If you would like to test OpenFaaS running on a cluster in AWS, a Terraform module and instructions can be found here: faas-nomad/terraform at master · hashicorp/faas-nomad · GitHub

Regardless of which method you use interacting with OpenFaaS is the same.

Running the OpenFaaS application

First, we need to start the OpenFaaS application, to do this there are two job files located in the folder nomad_job_files which set things up using sensible defaults. To run the main application execute the following command:

$ nomad run ./nomad_job_files/faas.hcl

==> Monitoring evaluation "a3e54faa"
    Evaluation triggered by job "faas-nomadd"
    Allocation "28f60a54" created: node "867c6baa", group "faas-nomadd"
    Allocation "7223b65d" created: node "d196a533", group "faas-nomadd"
    Allocation "a4dbae6c" created: node "123e18c0", group "faas-nomadd"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "a3e54faa" finished with status "complete"

This job will start an instance of the OpenFaaS gateway and the Nomad provider on every node in the cluster.

We can then launch the monitoring job to start Prometheus and Grafana:

$ nomad run ./nomad_job_files/monitoring.hcl

==> Monitoring evaluation "7d9c46df"
    Evaluation triggered by job "faas-monitoring"
    Allocation "e20ace08" created: node "123e18c0", group "faas-monitoring"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "7d9c46df" finished with status "complete"

This job starts a single instance of Prometheus and Grafana on the Nomad cluster.

Setting up Grafana to view application metrics

If you are not using the provided Terraform module, you will need to locate the node which Grafana is running on, assuming you have not changed the job file the port will be 3000. To log into Grafana use the default username and password admin.

Once you have successfully logged in, the next step is to create a data source for the Prometheus server.

Configure the options as shown ensuring that the URL points to the location of your Prometheus server. The next step is to add a dashboard to view the data from the OpenFaaS gateway and provider. A simple dash can be found at grafana\faas-dashboard.json, let's add this to Grafana. Clicking the Import button from the Dashboards menu will pop up a box like the one below. Choose the file for the example dashboard and press import.

Assuming all went well, you should now see the dashboard in Grafana:

Creating and deploying a function

To create functions, we can install the faas-cli tool, to get the CLI tool you can run the following command:

$ curl -sL https://cli.openfaas.com | sudo sh

Alternately if you are using a Mac, the cli is also available via brew install faas-cli

Creating a new function

Changing to a new folder we can create a new function by running the following command in the CLI:

$ faas-cli new gofunction -lang go
#...
2017/11/17 11:35:49 Cleaning up zip file...

Folder: gofunction created.
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|


Function created in folder: gofunction
Stack file written: gofunction.yml

The command will create two folders and one file in the current directory:

$ tree -L 1  
.
├── gofunction
├── gofunction.yml
└── template

2 directories, 1 file

The gofunction folder is where the source code for your application will live by default there is the main entry point called handler.go:

package function

import (
    "fmt"
)

// Handle a serverless request
func Handle(req []byte) string {
    return fmt.Sprintf("Hello, Go. You said: %s", string(req))
}

The Handle method receives the payload sent by calling the function as a slice of bytes and expects any output to be returned as a string. For now, let's keep this function the same and run through the steps for building the function. The first thing we need to do is to edit the gofunction.yml. file and change the image name so that we can push this to a Docker repo that our Nomad cluster will be able to pull. Also, change the gateway address to the location of your OpenFaaS gateway. Changing the gateway in this file saves us providing the location as an alternate parameter.

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

functions:
  gofunction:
    lang: go
    handler: ./gofunction
    image: nicholasjackson/gofunction

Building our new function

Next step is to build the function; we can do this with the faas-cli build command:

$ faas-cli build -yaml gofunction.yml 
#...
Step 16/17 : ENV fprocess "./handler"
 ---> Using cache
 ---> 5e39e4e30c60
Step 17/17 : CMD ./fwatchdog
 ---> Using cache
 ---> 2ae72de493b7
Successfully built 2ae72de493b7
Successfully tagged nicholasjackson/gofunction:latest
Image: gofunction built.
[0] < Builder done.

The build command execute the Docker build command with the correct Dockerfile for your language. All code is compiled inside of the container as a multi-stage build before being packaged into an Image.

Pushing the function to the Docker repository

We can either use the faas-cli push command to push this to a Docker repo, or we can manually push.

$ faas-cli push -yaml gofunction.yml 
[0] > Pushing: gofunction.
The push refers to a repository [docker.io/nicholasjackson/gofunction]
cc9df684d32a: Pushed 
4e12ae9c1d69: Pushed 
cdcffb5144dd: Pushed 
10d64a26ddb0: Pushed 
dbbae7ea208f: Pushed 
2aebd096e0e2: Pushed 
latest: digest: sha256:57c0143772a1e6f585de019022203b8a9108c2df02ff54d610b7252ec4681886 size: 1574
[0] < Pushing done.

Deploying the function

To deploy the function we can again use the faas-cli tool to deploy the function to our Nomad cluster:

$ faas-cli deploy -yaml gofunction.yml
Deploying: gofunction.
Removing old function.
Deployed.
URL: http://192.168.1.113:8080/function/gofunction

200 OK

If you run the nomad status command, you will now see the additional job running on your Nomad cluster.

$ nomad status
ID                   Type     Priority  Status   Submit Date
OpenFaaS-gofunction  service  1         running  11/17/17 11:52:59 GMT
faas-monitoring      service  50        running  11/15/17 14:43:11 GMT
faas-nomadd          system   50        running  11/15/17 11:00:31 GMT

Running the function

To run the function, we can simply curl the OpenFaaS gateway and pass our payload as a string:

$ curl http://192.168.1.113:8080/function/gofunction -d 'Nic'
Hello, Go. You said: Nic

or you can use the cli

$ echo "Nic" | faas-cli --gateway http://192.168.1.113:8080/ invoke gofunction

That is all there is to it, checkout the OpenFaaS community page for some inspiration and other demos. faas/community.md at master · openfaas/faas · GitHub

Datacenters and Limits

By default, the Nomad provider will use the datacenter of the Nomad agent or dc1. This can be overridden by setting one or more constraints datacenter == value. Limits for CPU and memory can also be set memory is an integer representing Megabytes, cpu is an integer representing MHz of CPU where 1024 equals one core.

i.e.

$ faas-cli deploy --constraint 'datacenter == dc1' --constraint 'datacenter == dc2'

or from a stack file...

functions:
  facedetect:
    lang: go-opencv
    handler: ./facedetect
    image: nicholasjackson/func_facedetect
    limits:
      memory: 512
      cpu: 1000
    constraints:
      "datacenter == test1"

Nomad Job Constraints

Additionally to the datacenter constraint Nomad job constraints are supported.

i.e.

$ faas-cli deploy --constraint '${attr.cpu.arch} = arm'

For compatibility and convenience the interpolation notation (${}) can be left out and == instead of = is supported.

All provided constraints are applied to the job (not the group or the task). Leaving out the a field (.e.g. ${meta.foo} is_set) or using more than one operator (e.g. ${meta.foo} is_set = bar) is currently not supported.

Annotations

Metadata can be added to the Nomad job definition through the use of the OpenFaaS annotation config. The below example would add the key git to the Meta section of nomad job definition which can be accessed through the API.

functions:
  facedetect:
    lang: go-opencv
    handler: ./facedetect
    image: nicholasjackson/func_facedetect
    annotations:
      git: https://github.com/alexellis/super-pancake-fn.git

Secrets API

It is possible to integrate Vault secrets https://docs.openfaas.com/reference/secrets/ with the Nomad provider. Follow these steps to have OpenFaaS integrate with Nomad + Vault:

  1. First, we need to enable the approle auth backend in Vault:

    vault auth enable approle

  2. We also need to create a policy for faas-nomad and OpenFaaS functions:

    vault policy write openfaas policy.hcl

    Policy file example: https://raw.githubusercontent.com/hashicorp/faas-nomad/master/provisioning/scripts/policy.hcl

    It is important that the policy contain: create, update, delete and list capabilities that match your secret backend prefix. In this case, path secret/openfaas/* will work with the default configuration.

    Also, faas-nomad takes care of renewing it's own auth token, so we need to make sure the policy uses path "auth/token/renew-self" and has the "update" capability.

  3. Finally, let's setup the approle itself:

    curl -i \
      --header "X-Vault-Token: ${VAULT_TOKEN}" \
      --request POST \
      --data '{"policies": ["openfaas"], "period": "24h"}' \
      https://${VAULT_HOST}/v1/auth/approle/role/openfaas

    This creates the role attached to the policy we just created. The "period" property and duration is important for renewing long-running service Vault tokens.

    curl -i \
      --header "X-Vault-Token: ${VAULT_TOKEN}" \
      https://${VAULT_HOST}/v1/auth/approle/role/openfaas/role-id

    Produces the role_id needed for -vault_app_role_id cli argument.

    curl -i \
      --header "X-Vault-Token: ${VAULT_TOKEN}" \
      --request POST \
      https://VAULT_HOST}/v1/auth/approle/role/openfaas/secret-id

    Produces the secret_id needed for -vault_app_secret_id cli argument.

Let's assume the Vault parameters have been populated, and you're now running faas-nomad along with the other OpenFaaS components. Now, try out the new faas-cli secret commands:

faas-cli secret create grafana_api_token --from-literal=foo --gateway ${FAAS_GATEWAY}

Now we can use our newly created secret "grafana_api_token" in a new function we want to deploy:

faas-cli deploy --image acornies/grafana-annotate --secret grafana_api_token --env grafana_url=http://grafana.service.consul:3000

Async functions

OpenFaaS has the capability to immediately return when you call a function and add the work to a nats streaming queue. To enable this feature in addition to the OpenFaaS gateway and Nomad provider you must run a nats streaming server.
To run the server please use the nats.hcl job file.

$ nomad run ./nomad_job_files/nats.hcl

You can then invoke a function using the async-function API, the call will be immediately retuned and OpenFaaS will queue your work for later execution.

curl -d '{...}' http://gateway:8080/async-function/{function_name}

Configuration and Function timeouts

By Default a function is allowed to run for 30s before it is terminated, should you require longer running functions timeout is configurable by setting the flag -function_timeout on the Nomad provider e.g:

 args = [
   "-nomad_region", "${NOMAD_REGION}",
   "-nomad_addr", "${NOMAD_IP_http}:4646",
   "-consul_addr", "${NOMAD_IP_http}:8500",
   "-statsd_addr", "${NOMAD_ADDR_statsd_statsd}",
   "-node_addr", "${NOMAD_IP_http}",
   "-logger_format", "json",
   "-logger_output", "/logs/nomadd.log"
   "-function_timeout", "5m"
]

This would set the timeout to 5m for a function.

Contributing

The application including docker containers is built using goreleaser https://goreleaser.com.

Setup

  • Clone this repo: go get github.com/hashicorp/faas-nomad
  • Create a fork in your own github account
  • Add a new git remote to $GOPATH/src/hashicorp/faas-nomad with your fork git remote add fork [email protected]:/yourname/faas-nomad.git

Building the application

make build_all this runs the command goreleaser -snapshot -rm-dist -skip-validate

Testing the application

make test runs all unit tests in the application, for continuous test running try http://goconvey.co

faas-nomad's People

Contributors

acornies avatar acornies-tc avatar alexellis avatar cpitkin avatar cryptobias avatar hxalid avatar jsoref avatar jusso-dev avatar mocofound avatar nicholasjackson avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

faas-nomad's Issues

incorrect tag in faas-nomad image

When updating faas-nomad Nomad failed to find the correct image from Quay.io

What are the steps to reproduce this issue?

  1. Clone faas-nomad repo
  2. Run nomad run faas.hcl

What happens?

Nomad logs

failed to initialize task "nomadd" for alloc "6571a6f0-1d46-9d1c-15dc-2fcc9317ea0e": Failed to pull `quay.io/nicholasjackson/faas-nomad:0.2.22`: API error (404): {"message":"manifest for quay.io/nicholasjackson/faas-nomad:0.2.22 not found"} 

What were you expecting to happen?

Nomad logs:

Task started by client

Any other comments?

PR to fix coming soon.

What versions of software are you using?

Operating System: Ubuntu 16.04 LTS

OpenFaaS Version: 0.2.22

Nomad Version: 0.7.1

Basic auth not implemented (Vault in future)

What are the steps to reproduce this issue?

  1. install faas-cli, trigger faas-cli login -address ...
  2. trigger a system endpoint

What happens?

faas-nomad is open internally, no auth strategy

What were you expecting to happen?

faas-nomad respects basic auth passed in from gateway, and by default basic auth should be on?

Any logs, error output, etc?

N/A

Any other comments?

Creating this issue for tracking. I believe there is support for this in the faas-provider now, so it's just a matter of implementing that to get parity with other providers and improving from there.

What versions of software are you using?

Operating System: Ubuntu 16.04 x64

OpenFaaS Version: 0.9.2

Nomad Version: 0.2.27

startNomad.sh does not work on Ubuntu 18 running on OpenSUSE

(Thanks for reporting an issue! Please make sure you click the link above to view the issue guidelines, then fill out the blanks below.)

What are the steps to reproduce this issue?

Just run source startNomad.sh and you will see that it is getting the wrong IP address

image

The command ip route get 1 | awk '{print $NF;exit}' is what is wrong

image

It was suppose to get what is between src and uui, but instead it is returning 1000

image

What were you expecting to happen?

It should get the right IP Address.

Any logs, error output, etc?

consul.log

nohup: ignoring input
==> 2 errors occurred:
	* advertise_addr: invalid ip address: 1000
	* advertise_addr: invalid ip address: 1000

Limited Ability to use Vault Secrets.

I've been trying to integrate openfaas-nomad into our stack, but a lot of our functions require access to various AWS S3 buckets to read/write data. The problem is that the openfaas-nomad vault integration only can access secrets at secrets/${secrets_dir}/${secret_name}. However, for our AWS secrets, we'd need to read secrets at aws/creds/${secrets_name}. Can i propose that we include the ability to customize this vault policy, instead of VaultDefaultPolicy: "openfaas"

Secondly, it would also be required to be able to specify the template that is rendered, as each read of the aws secrets generates a new set of two keys that need to be rendered simultaneously. The default template format
{{with secret "secret/${vault_prefix}/${secret_name}"}}{{.Data.${name}}}{{end}}
isn't suitable for this purpose.

So i propose that we also provide the ability to specify the policy and pass in a template block

functions:
  facedetect:
    lang: go-opencv
    handler: ./facedetect
    image: nicholasjackson/func_facedetect
    secrets:
      - mysecret 
        vault_policy: my_s3_secret_vault_policy
        template: |
[default] {{with secret "aws/creds/my_s3_secret"}}
aws_access_key_id={{.Data.access_key}}
aws_secret_access_key={{.Data.secret_key}}{{end}}

the vault policy my_s3_secret_vault_policy would just allow read access to aws/creds/my_s3_secret.

This example would generate a suitable AWS_CREDENTIALS_FILE at /etc/openfaas/secrets/mysecret that could be used to provide AWS api access.

Function resolving doesn't use consul dc filtering

What are the steps to reproduce this issue?

  1. … Deploy a function using consul with few different DC's
  2. … Try invoking it

What happens?

The function is not found because its not being searched for in the right DC

Maybe it can be solved by another flag? Ill try building an image with that and see if it helps

Mandatory update needed for `availableReplicas`

(Thanks for reporting an issue! Please make sure you click the link above to view the issue guidelines, then fill out the blanks below.)

Hi Nic,

A mandatory update is needed for OpenFaaS providers to work with the newest changes proposed in the OpenFaaS UI.

A new field: availableReplicas will need to be populated in the endpoint /system/function/<name>

I found the code here:

func MakeReplicationWriter(client nomad.Job, logger hclog.Logger, stats metrics.StatsD) http.HandlerFunc {

Now the purpose of this field is to indicate which functions (containers) have a replica ready for a HTTP request - often when pulling a large image the function is not ready until several minutes in. That's the purpose of this change - to provide that information to the UI or new endpoint.

You may need to vendor the latest release of faas-provider, which adds a healthcheck endpoint also.

https://github.com/openfaas/faas-provider/releases

The easiest way to maintain compatibility will be to set the availableReplicas count to be the same as replicas - this will mean the UI continues to work as planned. Down the road updating availableReplicas to its true meaning would be best.

Let me know if you have questions or if I can help.

Alex

What are the steps to reproduce this issue?

n/a

What happens?

Invoke button will be permanently disabled

What were you expecting to happen?

Button to be enabled.

Any logs, error output, etc?

(If it’s long, please paste to https://ghostbin.com/ and insert the link here.)

N/a

Any other comments?

As above

What versions of software are you using?

Operating System:

OpenFaaS Version:

0.7.5 and higher.

Nomad Version:

n/a

Question: Feasible to support volume mounts?

The request for Openfaas to directly allow volume mount options has been met with resistance (i.e. github.com/openfaas/faas/issues/320). But I wanted to know whether it would be a possibility for this provider plugin to extend access to the Nomad Job group settings in a way that volume and volume mount options could be passed in? Maybe through annotations? I figured if Openfaas wants to remain opinionated that a user should not be allowed to use mounts in a function, that is no reason that Nomad couldn't still remain flexible to the needs of users.

Thoughts?

For context, I have been evaluating different faas frameworks for a solution on top of k8s. But Nomad seems to suit some challenges at my studio. I was moving down the path of using Fission on k8s but now want to see whether Nomad can be an option, and reconsider using openfaas again (was my first choice) if volume mounting is no longer a problem.

Secrets

Provide capability to store and access secrets for a function using HashiCorp Vault.

This issue is currently blocked by the lack of E2E TLS in OpenFaaS, there is currently an open issue to resolve this.

Work round for Docker for Mac reporting ip as 127.0.0.1

When running Nomad under Docker for mac, the ip address for the function is registered as localhost, while this is fine for calling the function the proxy can not use this address as localhost is local to the container and not the address of the host.

A work around is to use the docker for mac host address docker.for.mac.localhost but this should be switched with an environment variable or another mechanism.

Support Consul ACL token

What are the steps to reproduce this issue?

  1. deploy faas-nomad and gateway with consul acls on
  2. deploy a function from the store (UI or faas-cli)

What happens?

If consul acls are on and the anonymous policy limits access to consul, functions cannot be invoked

What were you expecting to happen?

Functions can be invoked. However, this is to be expected when consul acl are on and faas-nomad doesn't provide the token to the consul resolver.

Any logs, error output, etc?

2018-10-03T19:12:57.843Z [INFO ] nomadd.reader_handler: List functions success
2018-10-03T19:12:59.454Z [INFO ] nomadd.consul_resolver: Got Address from cache: address="&consul.cacheItem{serviceQuery:(*dependency.CatalogServiceQuery)(0xc00009b4f0), addresses:[]string{}}"
2018-10-03T19:12:59.454Z [ERROR] nomadd.proxy_client: Function Not Found: figlet=<unknown>

Any other comments?

Adding this for tracking

What versions of software are you using?

Operating System: Ubuntu 1604 x64

OpenFaaS Version: 0.9.3

Nomad Version: 0.8.4

Update dependencies to Nomad 0.9

Given the release of Nomad 0.9, this provider should have updated Nomad Golang api dependencies. This is a big task as it basically means a full rewrite of the provider and tests.

Latest faas.hcl doesn't work.

What are the steps to reproduce this issue?

  1. check out v0.2.23
  2. nomad run nomad_job_files/faas.hcl

What happens?

Complains about the use of colons combined with "env = true" for nats addresses. Changing the colons to equal signs results in the jobs starting but the gateway just times out repeatedly trying to connect to nats. I see the connections appearing in /connz on the nats server, but then they disappear after a couple of seconds. It's also starting a nats server per node because its a system job but only using the last one. I can't imagine anyone bothered testing faas.hcl in v0.2.23 at all.

What were you expecting to happen?

Job starts and I can follow the tutorial.

Any logs, error output, etc?

2018/04/17 15:32:29 HTTP Read Timeout: 8s
2018/04/17 15:32:29 HTTP Write Timeout: 8s
2018/04/17 15:32:29 Binding to external function provider: http://x.x.x.x:18081/
2018/04/17 15:32:29 Async enabled: Using NATS Streaming.
2018/04/17 15:32:29 Opening connection to nats://x.x.x.x:4222
2018/04/17 15:32:31 stan: connect request timeout

repeated over and over.

Any other comments?

What versions of software are you using?

Operating System: centos 7

OpenFaaS Version: whatever's referenced by the v0.2.23 faas.hcl file

Nomad Version: 0.7.1

Support Consul as a DNS server using annotation or label

What are the steps to reproduce this issue?

  1. Deploy a function using the faas-cli w/ Nomad provider
  2. Your function has a Consul-style fqdn in it's environment vars
  3. Invoke your function

What happens?

Your function will fail due to the default dns server in the provider while using a consul FQDN

What were you expecting to happen?

Expecting failure, actually

Any logs, error output, etc?

lookup name.service.consul on 8.8.8.8:53: no such host

Any other comments?

Creating this for tracking purposes. I want to either support passing a dns_server or flag through either a label or annotation:

labels:
  dns_server: 1.2.3.4

or

labels:
  consul_dns: true

What versions of software are you using?

Operating System: Ubuntu 16.04 x64

OpenFaaS Version: 0.9.8

Nomad Version: 0.8.4

Scale up from zero does not work on Nomad

What are the steps to reproduce this issue?

  1. Provision OpenFaaS on an existing Nomad cluster and set scale_from_zero=true in the OpenFaaS gateway:
task "openfaas-gateway" {
      driver = "docker"
      template {
        env = true
        destination   = "secrets/gateway.env"

        data = <<EOH
             functions_provider_url="http://{{ env "NOMAD_IP_http" }}:8081/"
             {{ range service "openfaas-nats" }}
             faas_nats_address="{{ .Address }}"
             faas_nats_port={{ .Port }}{{ end }}
             EOH
      }

      config {
        image = "<my-registry>/openfaas/gateway:latest-dev"

        port_map {
          http = 8080
        }
      }

      resources {
        cpu    = 500 # 500 MHz
        memory = 128 # 128MB

        network {
          mbits = 10

          port "http" {
            static = 8080
          }
        }
      }
      service {
        port = "http"
        name = "openfaas-gateway"
        tags = ["v0.3.2",
                "openfaas"
                ]
      }

      env {
        faas_prometheus_host="my-prometheus-gateway"
        faas_prometheus_port=80
        scale_from_zero=true
      }
  }
  1. Deploy a simple function
provider:
  name: faas
  gateway: https://<my-gateway-url>

functions:
  echoer:
    lang: go
    handler: ./echoer
    image: <my-docker-registery>/faas-echoer:1.0.0
    labels:
      datacenters: "dev"
      com.openfaas.scale.min: 2
      com.openfaas.scale.max: 10
      com.openfaas.scale.factor: 20
      com.openfaas.scale.zero: true
    environment:
      read_debug: true
      write_debug: true
      print_response: true
  1. What happens?

echoer starts with 1 replication and after short time scales down to zero. Any subsequent requests returns Function Not Found:

curl --data "message" https://faas-gateway/function/echoer

What were you expecting to happen?

The number of replications would go up from zero to 1

Any logs, error output, etc?

2018/11/17 12:16:28 Version: 0.9.6	SHA: e33061702a8fc4d55bf8a8b7ba2f5dce87089c14
2018/11/17 12:16:28 Read/write timeout: 5s, 5s. Port: 8080
2018/11/17 12:16:28 Writing lock-file to: /tmp/.lock
2018/11/17 12:17:41 Forking fprocess.
2018/11/17 12:17:41 Query  
2018/11/17 12:17:41 Path  /
2018/11/17 12:17:41 Duration: 0.005614 seconds
2018/11/17 12:18:08 SIGTERM received.. shutting down server in 5s
2018/11/17 12:18:08 Removing lock-file : /tmp/.lock
2018/11/17 12:18:13 No new connections allowed. Exiting in: 5s

Any other comments?

What versions of software are you using?

Operating System:
Ubuntu 16.04
OpenFaaS Version:
Latest OpenFaaS built from source
Nomad Version:
Nomad v0.8.6

Support HCL/JSON file configuration

The ever-growing list of configuration parameters as arguments is unsustainable. Therefore, faas-nomad should support HCL/JSON file configuration for the provider with cli overrides for certain things:

faas-nomad -config-file=faas-nomad.hcl ...

Support Docker labels and or annotations for functions

What are the steps to reproduce this issue?

  1. Deploy faas-nomad components in local environment
  2. Write a new function, add some arbitrary labels in the {function}.yml
  3. Deploy the function with faas-cli, and check the http://{gateway}:8080/system/functions endpoint

What happens?

Deployed functions do not carry over Docker driver labels with Nomad provider.

What were you expecting to happen?

Nomad would honor a generic map of labels, defined in the labels directive in the function.yml upon deployment.

Any logs, error output, etc?

The json response is always "labels":null using http://{gateway}:8080/system/functions

Any other comments?

Looking at some more recent contributions to the openfaas/kafka-connector, it appears that annotations supersede labels in this case. I'd like to get the kafka connector working with the faas-nomad provider. I will attempt a PR, but was wondering if this was on your radar?

What versions of software are you using?

Operating System: Ubuntu 16.04
OpenFaaS Version: 0.8.3
Nomad Version: 0.8.4

OpenFaaS gateway not running using faas.hcl

What are the steps to reproduce this issue?

  1. source ./startNomad.sh
  2. nomad run ./nomad_job_files/faas.hcl
  3. nomad run ./nomad_job_files/monitoring.hcl
  4. faas-cli new gofunction -lang go
  5. update gofucntion.yml for the image name
  6. faas-cli build -yaml gofunction.yml
  7. faas-cli push -yaml gofunction.yml
  8. faas-cli deploy -yaml gofunction.yml

What happens?

Deploying: gofunction.

Is FaaS deployed? Do you need to specify the --gateway flag?
Put http://127.0.0.1:8080/system/functions: dial tcp 127.0.0.1:8080: getsockopt: connection refused

What were you expecting to happen?

Deploying: gofunction.
Removing old function.
Deployed.
URL: http://127.0.0.1:8080/function/gofunction

200 OK

Any other comments?

To resolve the issue I have observed that running docker swarm and deploy_stack from https://github.com/openfaas/faas works.

  1. docker swarm init
  2. ./deploy_stack.sh

Scaling to zero using the faas-idler

Hi,

What is the timeline of adding faas-idler to faas-nomad? if this is going to take so long, is there a workaround solution for scale to zero when for inactivity when deploy OpenFaaS to Nomad ?

TLS

Implement ability to bind nomad provider to a TLS endpoint by providing, key, cert, cert-chain

Function secrets need default Vault policy

What are the steps to reproduce this issue?

  1. Use the UI or faas-cli to deploy a function w/ one or more secrets using the Nomad provider

What happens?

Function is never "ready" due to missing Vault policy in certain Nomad configurations

What were you expecting to happen?

Functions can be deployed with secrets using Vault Nomad integration

Any logs, error output, etc?

N/A

Any other comments?

When a Nomad client is configured with a Vault master token this isn't a problem, but when Nomad Vault integration is configured to request token on-the-fly for functions (from the Nomad servers) a policy is needed to this behaviour to work.

What versions of software are you using?

Operating System: Ubuntu 16.04 x64

OpenFaaS Version: 0.9.3

Nomad Version: 0.8.4

Issue in Vagrant up

What are the steps to reproduce this issue?

  1. Vagrant up

What happens?

    default: Error querying node status: Get https://192.168.50.2:4646/v1/nodes: dial tcp 192.168.50.2:4646: connect: connection refused
    default: Error querying node status: Get https://192.168.50.2:4646/v1/nodes: dial tcp 192.168.50.2:4646: connect: connection refused
    default: Error querying node status: Get https://192.168.50.2:4646/v1/nodes: dial tcp 192.168.50.2:4646: connect: connection refused
    default: Error querying node status: Get https://192.168.50.2:4646/v1/nodes: dial tcp 192.168.50.2:4646: connect: connection refused
    default: Error querying node status: Get https://192.168.50.2:4646/v1/nodes: dial tcp 192.168.50.2:4646: connect: connection refused
    default: Error querying node status: Get https://192.168.50.2:4646/v1/nodes: dial tcp 192.168.50.2:4646: connect: connection refused
    default: Error querying node status: Get https://192.168.50.2:4646/v1/nodes: dial tcp 192.168.50.2:4646: connect: connection refused
    default: Error querying node status: Get https://192.168.50.2:4646/v1/nodes: dial tcp 192.168.50.2:4646: connect: connection refused

What were you expecting to happen?

Complete the vagrant setup successfully.

What versions of the software are you using?

Operating System:
macOS Catalina v10.15.5

OpenFaaS Version:

Nomad Version:

Local install doesn't start

(Thanks for reporting an issue! Please make sure you click the link above to view the issue guidelines, then fill out the blanks below.)

What are the steps to reproduce this issue?

  1. git clone https://github.com/hashicorp/faas-nomad.git
  2. cd faas-nomad
  3. ./startNomad.sh (after adding a further grep to the script to ensure my RFC1918 interface is chosen) (OK)
  4. vagrant up

What happens?

$ consul version
Consul v1.4.4
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

$ nomad version
Nomad v0.9.0 (18dd59056ee1d7b2df51256fe900a98460d3d6b9)

$ vagrant version
Installed Version: 2.2.4
Latest Version: 2.2.4

$ VBoxManage --version
5.2.26r128414

$ uname -a
Darwin myMac.my.net 17.7.0 Darwin Kernel Version 17.7.0: Wed Feb 27 00:43:23 PST 2019; root:xnu-4570.71.35~1/RELEASE_X86_64 x86_64

$ vagrant up
<errors - see below>

What were you expecting to happen?

Vagrant to deliver 1+ docker hosts with the stack running

Any logs, error output, etc?

All went OK until:

# Enabling the service here to ensure each state is independent.
nomad-service:
  service.running:
    - name: nomad
    # Restart service if config changes
    - restart: True
    - enable: True
[DEBUG   ] Results of YAML rendering:
OrderedDict([(u'nomad-config', OrderedDict([(u'file.serialize', [OrderedDict([(u'name', u'/etc/nomad/nomad.hcl')]), OrderedDict([(u'formatter', u'json')]), OrderedDict([(u'dataset_pillar', u'nomad:config')]), OrderedDict([(u'mode', 640)]), OrderedDict([(u'user', u'root')]), OrderedDict([(u'group', u'root')]), OrderedDict([(u'watch_in', [OrderedDict([(u'service', u'nomad-service')])])])])])), (u'nomad-service', OrderedDict([(u'service.running', [OrderedDict([(u'name', u'nomad')]), OrderedDict([(u'restart', True)]), OrderedDict([(u'enable', True)])])]))])
[PROFILE ] Time (in seconds) to render '/var/cache/salt/minion/files/dev/nomad/config.sls' using 'yaml' renderer: 0.00392889976501
[DEBUG   ] LazyLoaded highstate.output
local:
    Data failed to compile:
----------
    Rendering SLS 'dev:nomad.install' failed: Jinja variable 'salt.utils.odict.OrderedDict object' has no attribute 'data_dir'
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

Any other comments?

What versions of software are you using?

Operating System: macOS 10.13.6 (17G6030)

OpenFaaS Version: 0.8.4 cli

Nomad Version: 0.9.0

Load Tests + Performance Tuning

Results of load testing should be published with the provider. Initial testing has been carried out however publishing the full methodology and results is required.

Following analysis of the results performance tweaks may need to be made to certain aspects of the provider such as the http clients and load balancer configuration. This should be a methodological and incremental approach.

Repo title/desc

Hey guys,

Could the repo Desc be "Open FaaS plugin for Nomad" -> "OpenFaaS plugin for Nomad"?

For website we have a link back to the main repo for Rancher/K8s providers.

com.openfaas.scale.max and com.openfaas.scale.min have no impact on the minimum and maximum number of replicas

(Thanks for reporting an issue! Please make sure you click the link above to view the issue guidelines, then fill out the blanks below.)

What are the steps to reproduce this issue?

  1. Deploy OpenFaaS on an existing Nomad cluster
  2. Create and deploy a simple function as
provider:
  name: faas
  gateway: https://openfaas-gateway

functions:
  bcrypt:
    lang: go
    handler: ./bcrypt
    image: "<myregistry>/faas-bcrypt:1.0.0"
    labels:
      datacenters: "dev"
      com.openfaas.scale.min: "2"
      com.openfaas.scale.max: "5"
      com.openfaas.scale.factor: "20"
      com.openfaas.scale.zero: true
    environment:
        read_timeout: 20s
        write_timeout: 20s
        write_debug: true
  1. Load test using some tools, such as Vegeta, to increase the number of replicas.

What happens?
It goes up to 20

What were you expecting to happen?
It should not go beyond com.openfaas.scale.max, which is 5.

Any logs, error output, etc?

curl -s https://openfaas-gateway/system/function/bcrypt   | jq
{
  "name": "bcrypt",
  "image": "",
  "invocationCount": 0,
  "replicas": 1,
  "envProcess": "",
  "availableReplicas": 1,
  "labels": null,
  "annotations": null
}


curl -s https://openfaas-gateway/system/functions   | jq
[
  {
    "name": "bcrypt",
    "image": "<myregistry>/faas-bcrypt:1.0.0",
    "invocationCount": 10,
    "replicas": 1,
    "envProcess": "",
    "availableReplicas": 0,
    "labels": {
      "com.openfaas.scale.factor": "20",
      "com.openfaas.scale.max": "5",
      "com.openfaas.scale.min": "2",
      "com.openfaas.scale.zero": "true",
      "datacenters": "dev"
    },
    "annotations": null
  }
]

Any other comments?

What versions of software are you using?

Operating System:
Ubuntu 16.04

OpenFaaS Version:

"version": {
    "commit_message": "Add OpenFest and IstaCon events in November",
    "sha": "b1d1fe21e0c54611715f8eac611ca98134a342f6",
    "release": "dev"
  }

Nomad Version:
Nomad v0.8.6

Build error "cannot use statsD" in "handlers/proxy.go:148:42"

What are the steps to reproduce this issue?

  1. Clone the Git repo with go get github.com/hashicorp/faas-nomad
  2. run make build or make build_all

What happens?

The compile stops with the following error message:

# github.com/hashicorp/faas-nomad/handlers
handlers/proxy.go:148:42: cannot use statsD (type *"github.com/DataDog/datadog-go/statsd".Client) as type *"github.com/nicholasjackson/ultraclient/vendor/github.com/DataDog/datadog-go/statsd".Client in argument to ultraclient.NewDogStatsDWithClient

Any other comments?

I'd like to get the build working locally so I can add more constraints to the nomad provider as I need to be able to use node_class as a constraint to target specific Nomad agents.

What versions of software are you using?

Operating System: CentOS 7.5 Kernel 4.17

OpenFaaS Version: as per default in the faas-nomad repo

Nomad Version: 0.8.6

Gateway return function not found when run through traefik

What are the steps to reproduce this issue?

  1. Deploy using faas.hcl
  2. Add a function with UI or cli
  3. Try to get to the function through the gatway

What happens?

Yields a 404 Function not found

What were you expecting to happen?

To get results from the function

Any logs, error output, etc?

2018-12-30T23:34:15.224Z [INFO ] nomadd.consul_resolver: Getting Address from consul: function=certinfo
2018-12-30T23:34:15.225Z [ERROR] nomadd.proxy_client: Function Not Found: certinfo=<unknown>

Any other comments?

My nomad cluster is pre-built on node that runs CoreOS. HTTP proxy is done with traefik through the consul_catalog provider within traeifk. Consul services are exported by their name to a specific domain.

I'm not totally sure on how all the pieces works together but the functions are launched through nomad without issues. I also can reach the function itself through traefik because it's service was registered in consul. Trying to use the function through the /function/<name> with the gateway doesn't work.

What versions of software are you using?

Operating System: CoreOS

OpenFaaS Version: latest with current master of this repo

Nomad Version: 0.8.6

Detect the configured DC from nomad or consul agent

What are the steps to reproduce this issue?

  1. Deploy faas-nomad and gateway using a nomad/consul DC name other than dc1
  2. In the gateway UI or faas-cli, deploy a function from the store

What happens?

The function tries to deploy to DC dc1 instead of the configured DC from the nomad or consul agent

What were you expecting to happen?

The function is deployed with the agent's configured DC

Any logs, error output, etc?

No nodes were eligible for evaluation
No nodes are available in datacenter dc1

Any other comments?

Adding this issue for tracking, will tackle it shortly.

What versions of software are you using?

Operating System: Ubuntu 1604 x64

OpenFaaS Version: 0.9.3

Nomad Version: 0.8.4

Local Vagrant environment for portable integration testing

Since this feature doesn't quite fit the issue template, I'll outline it below:

Provide a portable Vagrant environment via Vagrantfile that can:

  • Provision entire Hashicorp stack (Docker, Consul, Nomad, Vault) in a standalone VM
  • Run OpenFaaS components using Nomad w/ Docker
  • Add debugging launch configuration which connects faas gateway to faas-nomad
  • Assume Go development is done on host/workstation, the rest is provisioned in the VM
  • Facilitate integration testing for all supported features of OpenFaaS

Discussed briefly with @nicholasjackson, but wanted to track it.

Unexpected status: 502 when deploying function

What are the steps to reproduce this issue?

  1. faas-cli deploy -f ./gofunction.yml

What happens?

_Deploying: gofunction.

Unexpected status: 502, message:_

No error message is given except the empty message. Hints on how to debug this further would be very welcome

What versions of software are you using?

Operating System: Fedora 26
OpenFaaS Version: functions/gateway:0.6.14 & faas-nomad:0.2.16
faas-cli Version: 0.6.2
Nomad Version: 0.7.0

Function file:
provider:
name: faas
gateway: http://10.48.4.59:8080

functions:
gofunction:
lang: go
handler: ./gofunction/handler
image: rogerw/gofunction

There is nothing running on port 8080 after running the job faas.hcl

What are the steps to reproduce this issue?

1 - Follow the instructions from the README on a Ubuntu 18 VM running on OpenSUSE
2 - After running the job faas.hcl check that there is nothing on port 8080. You can't access through the browser nor with curl or ping.
3 - check with sudo docker ps that there is no container mapped to port 8080
image

4 - check that the port 8080 is not being used by any other process or service with sudo lsof -i -P -n | grep LISTEN
image

5 - check on Consul UI that Gateway is not listed and everything is Healthy. Also, it sometimes appears and disapears (WHY?)

image

6 - check the stderr logs for the gateway task are complaining only about nats not available, when it is available:

image

image

What happens?

The faas.hcl is not throwing any errors and the container does not start on port 8080

What were you expecting to happen?

The Open faas gateway should be running on port 8080. So I could deploy my function or access the UI.

image

Obs: On Consul UI I was seeing Gateway service appearing and disapearing. Why?

Additional Information

Ubuntu, Docker, Nomad and Consult versions:
image

Auto Scaling is not working

What are the steps to reproduce this issue?

  1. Deploy OpenFaaS on Nomad cluster
  2. Deploy simple NodeJS (V12) function
version: 1.0
provider:
  name: openfaas
  # This can be override upon request/need
  gateway: http://192.168.0.17:8080
functions:
  fibfunction:
    lang: node12
    handler: ./fibfunction
    image: mabuaisha/fibfunction:latest
    labels:
      datacenters: "dc1"
      com.openfaas.scale.min: "3"
      com.openfaas.scale.max: "5"
      com.openfaas.scale.factor: "20"
    environment:
      read_timeout: 20s
      write_timeout: 20s
      write_debug: true

The above is the configuration for simple nodejs12 specified as the following

module.exports = async (event, context) => {
  let number = event['body'];
  number = number.replace(/\n/g, '');
  // console.log(event);
  // console.log(context);
  //
  //   if (!number || !isNumeric(number)) {
  //       return context
  //           .status(400)
  //           .fail(createErrorResponse("Please pass a valid number 'number'."));
  //   }
  //
  //   number = parseInt(number);
  //   const result = fib(number);

  return context
    .status(200)
    .succeed({'result': number})
};

What happens?

It never create 3 instances of the function based on the com.openfaas.scale.min: "3" and cannot see the auto scaling is working.

I'm testing ab -n 100000 -c 40 -p ab.data -T "content-type: text/plain" http://192.168.0.17:8080/function/fibfunction

But never scale automatically

What were you expecting to happen?

  1. Set the initial number of functions based on the value set on com.openfaas.scale.min=3
  2. Auto scaling automatically for heavy load

Any logs, error output, etc?

 curl -s http://192.168.0.17:8080/system/function/fibfunction | jq
{
  "name": "fibfunction",
  "image": "mabuaisha/fibfunction:latest",
  "invocationCount": 0,
  "replicas": 1,
  "envProcess": "",
  "availableReplicas": 1,
  "labels": {
    "com.openfaas.scale.factor": "20",
    "com.openfaas.scale.max": "5",
    "com.openfaas.scale.min": "3",
  },
  "annotations": null
}
curl -s http://192.168.0.17:8080/system/info | jq
{
  "provider": {
    "provider": "",
    "version": {
      "sha": "",
      "release": "0.3.6"
    },
    "orchestration": "nomad"
  },
  "version": {
    "commit_message": "Update swagger for missing secret definitions",
    "sha": "a65df4795bc66147c41161c48bfd4c72f60c7434",
    "release": "0.9.14"
  }
}

What versions of software are you using?

Operating System:
Centos 7

OpenFaaS Version:
0.9.14

Nomad Version:
0.10.2

This is somehow similar to this issue #61

@acornies your help on this much appreciated

Add constraints

Add the ability to add a constraint to a function to restrict the architecture for a function:

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

functions:  
  ipconfig:
    image: alexellis/windows-ipconfig:nano
    skip_build: true
    environment:
      suppress_lock: true
    constraints:
      - "node.platform.os == windows"
      - "node.datacenter == dc2"

In this instance the function would only be deployed to a node running windows

typo in file nomad_job_files/faas.hcl

(Thanks for reporting an issue! Please make sure you click the link above to view the issue guidelines, then fill out the blanks below.)

What are the steps to reproduce this issue?

  1. nomad run -verbose ./nomad_job_files/faas.hcl

What happens?

faas-nomadd fails with error :

Template: error parsing env template "secrets/gateway.env": error on line 6: missing =


To fix it edit the file faas.hcl
change
functions_provider_url="http://{{ env "NOMAD_IP_http" }}:8081/"
{{ range service "prometheus" }}
faas_prometheus_host="{{ .Address }}"
faas_prometheus_port="{{ .Port }}"{{ end }}
{{ range service "nats" }}
faas_nats_address: "{{ .Address }}"{{ end }}
faas_nats_port: 4222

EOH

to

functions_provider_url="http://{{ env "NOMAD_IP_http" }}:8081/"
{{ range service "prometheus" }}
faas_prometheus_host="{{ .Address }}"
faas_prometheus_port="{{ .Port }}"{{ end }}
{{ range service "nats" }}
faas_nats_address="{{ .Address }}"{{ end }}
faas_nats_port=4222
EOH

Implement /system/secrets and use Nomad's configured Vault API

What are the steps to reproduce this issue?

  1. download latest faas-cli ()
  2. download latest gateway >= 0.9.14
  3. try out faas-cli ~= 0.8.3 using faas-cli secret ...

What happens?

The secret endpoints are not yet supported.

Any other comments?

Adding this for tracking. The approach so far is to implement against Vault's API using the already-established convention of the default Vault policy and key prefix from faas-nomad.

Support of-watchdog http mode (status code)

What are the steps to reproduce this issue?

  1. Build and or deploy a function that uses of-watchdog in the image (tested with powershell-http)
  2. Invoke a function that expects a response code other than 200
  3. Check the gateway response code

What happens?

faas-nomad returns the default http response writer status code (200) instead of honoring the function status code itself.

What were you expecting to happen?

faas-nomad returns status code of upstream function

Any logs, error output, etc?

curl -i -XPOST -d 'this is a curl test' -H 'Custom-Header_Andrew: cat' http://192.168.50.2:8080/function/powershell-example
HTTP/1.1 200 OK
Content-Length: 75
Content-Type: text/plain; charset=utf-8
Date: Mon, 07 Jan 2019 17:47:35 GMT
Server: Microsoft-NetCore/2.0
X-Call-Id: 11ddf5d5-5bfe-4f59-83d3-2cfa289d28d3
X-Duration-Seconds: 0.004418
X-Start-Time: 1546883255454259180

Hello! Your input was: this is a curl test with alternate http status201int

Any other comments?

Adding this for tracking. Will open a PR for it shortly.

What versions of software are you using?

Operating System: Ubuntu 16.04 x64

OpenFaaS Version: 0.9.11

Nomad Version: 0.8.6

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.