Version 0.12.1 was tagged as 012.1.

Tools like dep are currently pulling it in as version 12.1.0, making it the latest release.

The proxy package needs to clearly support selecting functions by namespace in order to support

openfaas/faas-netes#511

Some, if not all of the packages in the gateway which deal with function CRUD and secret CRUD can be moved here:

https://github.com/openfaas/faas/tree/master/gateway/requests

The same is true of the faas-cli:

https://github.com/openfaas/faas-cli/tree/master/schema

Once moved, the code in faas/faas-cli can vendor back the version from here.

As proposed in openfaas/faas#1585 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.
Current Behaviour
We're running all our CI builds using Travis CI
Possible Solution
Move to Github Actions

Create a new endpoint, like /functions, with only the functions' names in a JSON format which can be called from an upper API in order to display them.

The JSON could be like this :

[
    {
        "name": "<function_name_1>",
        "labels": {
            "function": "true"
        }
    },
    {
        "name": "<function_name_2>",
        "labels": {
            "function": "true"
        }
    },
    {
        "name": "<function_name_3>",
        "labels": {
            "function": "true"
        }
    },
    {
        "name": "<function_name_...>",
        "labels": {
            "function": "true"
        }
    },
    {
        "name": "<function_name_n>",
        "labels": {
            "function": "true"
        }
    }
]

Note : This JSON is already used for the endpoint /system/functions with only "name" and "function" in "labels" keys

This will avoid any call to /system/functions and/or passing credential in a function or environment variables.
A feature of this endpoint can be to be allowed or not in a parameter when installing OpenFaas

The rename httputils -> httputil done in 8baf21d was not 100% complete. This results in a dep error because the package is malformed

Solving failure: No versions of github.com/openfaas/faas-provider met constraints:
	0.9.0: Could not introduce github.com/openfaas/[email protected], as it is not allowed by constraint ^0.9.2 from project github.com/openfaas/faas-swarm.
	0.9.2: "github.com/openfaas/faas-provider/proxy" imports "github.com/openfaas/faas-provider/httputils", which contains malformed code: no package exists at "github.com/openfaas/faas-provider/httputils"

We should

1. obviously fix the import, but also
2. add travisci so that this kind of mistake doesn't sneak in again

Update package references to point to openfaas/faas-provider from alexellis/faas-provider

faas-netes log

2022/01/14 10:07:51 error with proxy request to: http://10.32.130.24:8080, Post "http://10.32.130.24:8080\": context canceled

gateway logs

2022/01/14 10:07:51 Forwarded [POST] to /function/fn-2100e53c784e4a88a864449e78ba50b462703696.openfaas-fn-6ccc8843-d78d-49e8-84c4-3734a4af9929 - [500] - 120.004119s seconds

On our side we get a 500 containing "Can't reach service"
We have in the past also seen 502's without body for timeouts from https://github.com/openfaas/faas/blob/52d0165c3f22b5d1c269dd6e43e6e6bda6559936/gateway/handlers/forwarding_proxy.go#L132

Towards our users we would like to report this as a timeout, a few questions pop up:

• How do we know a response comes from the openfaas middleware vs the actual function? Maybe some specific headers can be set for all responses from openfaas proxies?
• How do we reconstruct this is a timeout from the generic "Can't reach service"? A standardized error response format would be welcome.
• Any reason why there is no standard log format in use on openfaas components where log level, namespace, deployment and other info can be filtered on?

Reported here as this repo came up searching for the error messages

The proxying code is repeated in faas-swarm, faas-netes, openfaas-operator and possibly faas-fargate/faas-nomad.

• https://github.com/openfaas/faas-swarm/blob/master/handlers/proxy.go
• https://github.com/openfaas/faas-netes/blob/master/handlers/proxy.go
• https://github.com/openfaas-incubator/openfaas-operator/blob/master/pkg/server/proxy.go

At least the code for the first three should be moved here.

The proxying code is rarely used apart from when direct_functions is set to false. For some reason Capital One need this feature, so we should move the code into one place for maintenance. Each provider will then be able to utilize the package.

A similar move was made for the basic auth middleware that I wrote.

In addition the path parsing/trimming code that passes a HTTP Path to functions needs to be ported over so that functions are not invoked with a PATH like /function/<name>/param1/param2 but with /param1/param2 directly. This code resides in the gateway currently and so it may make sense to also refactor it into a package here.

Summary/tasks

To test turn off direct_functions on your API gateway

• Refactor/move out the proxying code to a common type package here. Unit tests must be copied/added
• Add path trimming support to match the gateway's direct_functions approach

Once the above is done and we have a release of faas-provider:

• Remove code from each provider and have them vendor the package here

The logs request/response should include support for specifying the namespace to support

openfaas/faas-netes#511

This value can optionally be ignored depending on the provider implementation.

The read me provides a link to "server.go" describing the process for using the faas-provider package, but the link is broken:

on line 23: For an example see the server.go file in the faas-netes Kubernetes backend.

This struct https://github.com/openfaas/faas-provider/blame/master/types/requests.go#L12

Is actually used as a response, so it should be called InfoResponse. See https://github.com/openfaas/faas-swarm/blob/ecf4229ce7dea59ccf8bbf3f96e6f11a669ffe60/handlers/info.go#L18-L43 and https://github.com/openfaas/faas-netes/blob/85492c470c36065f8dc2bba59b5a212d7779a2e9/handlers/info.go#L21-L46

The current name can be confusing when implementing a new provider.

Also, it seems like we could probably completely standardize the the InfoHandler by passing the provider version info, name, and identifier to

I was about to open a PR for the Go modules migration when I realized that this Dockerfile may need to be updated https://github.com/openfaas/faas-provider/blob/master/Dockerfile

But then I realized I wasn't sure what it was for. It is not referenced in the CI flow or the Readme. It looks like it was an early demo prototype for how the faas-provider works. The Readme now references the concrete implementation in faas-netes, perhaps we can remove this Dockerfile?

While working on the certifier, I wanted to update the vendored code and I realized that many of the request structs had moved to the provider (see #22) but AsyncReport and DeleteFunctionRequest are both still in the gateway.

At the minimum it seems like we should move the delete request. the AsyncReport seems like a response type, not a request type, but it probably make sense to move it too.

Current behaviour

We get a general error then return a HTTP 404 status code, which may be confusing for consumers of the invocation endpoint in the gateway.

Expected behaviour

Return a typed error from the proxy when there are no endpoints available

Context

Returning an error such as 'no endpoints ready' could allow us to tell the gateway to retry an invocation.

Task

Update provider proxy to match gateway's settings

Context

The tuning done in the gateway copies that which Prometheus, Minio and other projects needed to implement cope with high requests per second.

• MaxIdleConns
• MaxIdleConnsPerHost

https://github.com/openfaas/faas/blob/master/gateway/types/proxy_client.go#L14

I was able to crash the proxy code and get time-outs / no files available with 50 concurrent requests in openfaas/faas-netes#533

Once this is complete, I'll revendor faas-provider and test again, I believe it will accept the higher concurrency since it relieved the issue in the gateway originally.

The "health" handler was renamed from "Health" to "HealthHandler" which is a breaking change and requires an upgrade to all providers:

• faas-swarm
• faas-netes
• openfaas-operator

Task:

• Checkout each provider
• Vendor https://github.com/openfaas/faas-provider/releases/tag/0.9.0 with dep ensure or an edit to Gopkg.toml
• Update the main or app or server.go to do the rename
• Build / make / test with Docker & go build
• Raise PR
• 👍

Schema change

Add created / updated into API for sorting / auditing

I had a use-case where I wanted to sort the functions by time created, and I couldn't find a way to do that with the function spec. This could also be useful for auditing purposes.

faas-netes

This is available in the Deployment spec already

faasd

The container creation date is probably available, but there isn't a way to update a container without re-creating it, so the created and modified dates would be the same.

Apologies if this was the intention! Just want to understand why we don't proxy the status code back on the response to the client. I got tripped up up debugging an issue where the upstream provider was returning 404, but downstream the response to the client was 200

When looking at the metrics, we see that the status code is sometimes 0.

We expect that this should actually be 200, not 0.

We found that this is caused by two issues in the middleware:

1. The HTTP response recorder used by the metrics middleware does not always set the status code on the first call to the Write method. To match the stdlb behavior, this should be setting the status code to 200, if it is not set yet.
2. when the metrics are recorded, it uses the StatusCode field instead of the Status() method, which protects against the 0 value.

The /system/id endpoint should reveal the provider name.

This will be called by the OpenFaaS gateway for external providers so we can for instance hide the "networking" field or show which orchestrator is being used.

https://github.com/openfaas/faas-provider/blob/master/serve.go#L24