workflows api proxy assumes that workflows is in the same namespace as fission

[soamvasani]

The fission controller proxy for the workflows apiserver doesn't work if workflows is installed in a different namespace from the fission controller.

$ wfcli status
panic: unknown error (status 502): {resp:0x10a78190} 

$ kubectl -n fission logs controller...
2017/10/25 15:53:42 http: proxy error: dial tcp: lookup workflows-apiserver on 10.43.240.10:53: no such host
127.0.0.1 - - [25/Oct/2017:15:53:42 +0000] "GET /proxy/workflows-apiserver/status HTTP/1.1" 502 0

To fix this, the proxy must either discover the workflows installation somehow (maybe through a configmap) or we should require workflows to be installed in the same namespace as fission (not even sure that's possible given that helm allows the user to override the installation namespace).

[texascloud]

I'm getting a similar error as what appears here, except in the fission workflows Pod. It's running in the same namespace as the Fission controller Pod.

time="2019-02-05T19:21:49Z" level=error msg="Action '*workflow.ActionParseWorkflow' failed: failed to resolve tasks in workflow: Get http://controller.fission/v2/functions/test-create-cloud-provider?namespace=fission-function: dial tcp: lookup controller.fission on 10.21.0.10:53: no such host" component=controller.workflow

[lmx2k5]

at least this could be mentioned in fission-workflow installation guide - following guide, workflows gets installed in default namespace. Could not get workflow CLI working without digging source code and realising that workflow was expected in same namespace as fission.