faas: Add missing attributes to /system/function/{functionName}

Expected Behaviour

Attributes used to create a function with the POST endpoint should be mirrored when retrieving the function meta data using the GET endpoint

Current Behaviour

The attributes are currently as follows:

Name	POST	GET
service	- [x]	- [x] - called `name`
network	- [x]	- [ ] - missing
image	- [x]	- [x]
envProcess	- [x]	- [x]
envVars	- [x]	- [ ] - missing
constraints	- [x]	- [ ] - missing
labels	- [x]	- [x]
annotations	- [x]	- [x]
secrets	- [x]	- [ ] - missing
registryAuth	- [x]	- [ ] - missing but maybe not include as its sensitive
limits	- [x]	- [ ] - missing
requests	- [x]	- [ ] - missing
readOnlyRootFilesystem	- [x] added	- [ ] - missing

Possible Solution

swagger.yml add missing attributes to FunctionListEntry
gateway/requests/requests.go add missing attributes to Function type
faas-swarm/handlers/reader.go add missing attributes in readServices func
faas-netes add missing attributes
faas-operator add missing attributes
faas-cli describe verb when merged may need updating

Context

I’m writing a terraform provider for openfaas, to work well with terraform, it’s best if the underlying infrastructure apis have mirrored POST/GET endpoints. This is also a very common practice in REST apis

About this issue

Original URL
State: open
Created 6 years ago
Comments: 35 (29 by maintainers)

Commits related to this issue

Add missing attr /system/function/{functionName} 1. Update swagger file to include attributes present in the POST endpoint but missing in the GET Relates to: #848 Signed-off-by: Edward Wilde <ewild... — committed to ewilde/faas by ewilde 6 years ago

Most upvoted comments

Let’s move this forward for faasd and faas-netes. Cc @Waterdrips @LucasRoesler

alexellis on Jan 14, 2021

We will be discussing this issue in our next members call. Will let you know where we get.

alexellis on Jun 16, 2019

Happy to go with option 1. However; looks like it would be a breaking change though, if I’ve understood the proposal correctly

To create a new function resource you would POST to /system/functions/spec and read the resource GET from /system/functions/{name}/spec. Presumably older versions of the cli would still POST to /system/functions and other components would read from /system/functions/{name}?

If we are to go with option 1, I would prefer to GET from /system/functions/spec/{name}, instead of /system/functions/{name}/spec/. Think that more closely aligns with a restful API. You are creating a function spec resource and reading the spec resource with the identifier {name}

ewilde on Sep 17, 2018

@alexellis if we are worried about the latency/size impact, we could

move this to subpaths, /system/functions/spec and /system/functions/{name}/spec. So that /system/functions would just be a summary.
Or add a nullable spec field and only include it if a GET parameter is sent.
Or add a nullable spec field and a GET parameter hide_spec to explicitly hide it in those cases where you don’t want it

I think option 1 is easier to document and maintain

LucasRoesler on Sep 17, 2018