I've build some Go based handlers and trying to build a pipeline of functions and I am seeing some surprising and totally unexpected results. I hope I am missing something here...
Say I have a function f1 that needs to call another function f2.
For instance I am building a pipeline as such: echo -n "blee" | f1() | f2() -> "blee doh"
where function f2 appends the string its given with another.
My function handlers looks something like this:
// F1
func Handle(req []byte) string {
log.Printf("F1 called with `%s`\n", string(req))
fmt.Println("F1 is happy as a hippo!")
return callF2(req)
}
// F2
func Handle(req []byte) string {
log.Printf("F2 called with `%s`\n", string(req))
fmt.Println("F2 is happy as a hippo!")
return string(req + " doh")
}Expected Behaviour
echo -n 'blee' | faas invoke f1
Yields...
Current Behaviour
echo -n 'blee' | faas invoke f1
Yields...
[2018/02/20 13:03:07] F1 called with blee
F1 is happy as a hippo!
[2018/02/20 13:03:07] F2 called with blee
F2 is happy as a hippo!
blee doh
NOTE: As you can see, tho I've specified I want my function to return the appended string
I am getting my logs and debug message as part of the response too?? I hope I am missing
something here as this makes it really rough to chain function especially in light of
marshalling/unmarshalling JSON in between calls! This totally hoarks my use case.
Possible Solution
Return what the user specifies no other io operations to stdout should be surfaced in the response!
Steps to Reproduce (for bugs)
- Deploy f1 go function
- Call f1 returns output from log.Println, fmt.Println + the returned string tho I specified return x in the call??
Context
I can't build a simple pipeline and try to mashall json responses in between function calls. Can't add
any debug stmt as this kill my json parse. This was highly surprising and unexpected. Trying to debug
my calls kills my whole pipeline!
A bigger note here is I am not really sure about the handler signature handle(string) string. At first I like
the simplicity of it, but now I am really not sure this is what's best especially in light of go function. Go provides nice constructs to formulate request/response via header, cookies, query params, etc and yet all these are gone with OpenFAAS. Resulting in having to parse out env vars and such to get the just of a function call. I think this limit this framework greatly for the use cases where one wants to configure the essence of a request ie I want to call f1 with a cookie that will affect how f1 behaves based on user input. I believe lang familiarity should be fully enable to function writers. In this case fully taking advantage of go http package make most sense as now one can leverage the full power of the language mechanics vs having to handle common http idioms via env vars. I do understand the lowest common denominator to span across langs but in the case I feel this negates the beauty and simplicity of this framework since as a function writer I really don't feel that empowered with string semantics. To boot tho I specify a return string signature this is not really my function output??
Your Environment
- Docker: 17.09
- OpenFAAS: 0.6.2
- K8s: 1.9
- Go: 1.10
- Are you using Docker Swarm or Kubernetes (FaaS-netes)?
Faasnetes
- Operating System and version (e.g. Linux, Windows, MacOS):
OSX
I've build some Go based handlers and trying to build a pipeline of functions and I am seeing some surprising and totally unexpected results. I hope I am missing something here...
Say I have a function f1 that needs to call another function f2.
For instance I am building a pipeline as such: echo -n "blee" | f1() | f2() -> "blee doh"
where function f2 appends the string its given with another.
My function handlers looks something like this:
Expected Behaviour
Current Behaviour
Possible Solution
Return what the user specifies no other io operations to stdout should be surfaced in the response!
Steps to Reproduce (for bugs)
Context
I can't build a simple pipeline and try to mashall json responses in between function calls. Can't add
any debug stmt as this kill my json parse. This was highly surprising and unexpected. Trying to debug
my calls kills my whole pipeline!
A bigger note here is I am not really sure about the handler signature handle(string) string. At first I like
the simplicity of it, but now I am really not sure this is what's best especially in light of go function. Go provides nice constructs to formulate request/response via header, cookies, query params, etc and yet all these are gone with OpenFAAS. Resulting in having to parse out env vars and such to get the just of a function call. I think this limit this framework greatly for the use cases where one wants to configure the essence of a request ie I want to call f1 with a cookie that will affect how f1 behaves based on user input. I believe lang familiarity should be fully enable to function writers. In this case fully taking advantage of go http package make most sense as now one can leverage the full power of the language mechanics vs having to handle common http idioms via env vars. I do understand the lowest common denominator to span across langs but in the case I feel this negates the beauty and simplicity of this framework since as a function writer I really don't feel that empowered with string semantics. To boot tho I specify a return string signature this is not really my function output??
Your Environment
Faasnetes
OSX
Link to your project or a code example to reproduce issue:
Please also follow the troubleshooting guide and paste in any other diagnostic information you have: