Unable to run functions in any other namespace than default

[erikedling]

So I'm just trying out kubeless through serverless and I'm currently running kubeless in my own namespace. I'm using the env KUBELESS_NAMESPACEso that the config-map can be found. If I'm deploying the functions in the default namespace, it works fine. However, if I add the field "namespace" in the serverless.yml file in order to deploy the functions in my own namespace as well like so

{
  provider:
    name: kubeless
    namespace: mynamespace
    runtime: nodejs6

  etc
}

And I run serverless invoke --function capitalize --data '"WELCOME TO KUBELESS!"' -l. I will get TypeError: opts.log is not a function in the file serverless-kubeless/lib/invoke.js:128:16.

If I log the "servicesInfo" variable in the same scope I get the following

{ 
  kind: 'ServiceList',
  apiVersion: 'v1',
  metadata: { 
    selfLink: '/api/v1/namespaces/default/services',
    resourceVersion: '129499598' },
    items: [ { metadata: [Object], spec: [Object], status: [Object] } ] 
}

I can see that it uses the default namespace and not the one specified in the serverless.yml file. Am I doing something completely wrong or Is this maybe not supported or is it a bug?

[andresmgot]

Hi @erikedling, from the description is not clear to me. When you change the namespace, are you able to deploy functions but you are not able to invoke them? Apparently that's the issue so yes, it could be a bug.

In any case, note that you can use the kubeless CLI to achieve what you want in case is a suitable option for you: `kubeless function call capitalize -d "WELCOME TO KUBELESS!"

The issue is probably in this line:

https://github.com/serverless/serverless-kubeless/blob/master/lib/invoke.js#L84

It's using connectionOptions which namespace is the default one. Can you try if modifying the namespace there solves your issue?

[erikedling]

Sorry about that but yes, when i set the "namespace" field under "provider" in serverless.yml it works to deploy in the specified namespace but not invoking the functions as it looks for the functions in the default namespace instead of the specified one.

Through kubeless CLI i can invoke with the following command: kubeless function call capitalize -d "WELCOME TO KUBELESS!" --namespace mynamespace.

If I set the namespace field in connectionOptions to the value from the namespace variable(existing in the scope of the "invoke" method) it works perfectly.

[andresmgot]

Great, since you have narrowed down the issue, would you mind sending a PR fixing it? If you bump the version of the package in the PR a new version will be automatically released.

[erikedling]

Absolutely, I might have time to put a PR up this weekend 😃

[erikedling]

I could do the easy fix changing the field in connectionOptions after it has been created in the invoke method however I would much rather have wanted to make sure helpers.getConnectionOptions does it correctly in the first place. Unfortunately I can't seem to get a local minikube instance up and running on my personal computer to test things and I don't have too much time fixing that. I'm sorry, could someone else maybe do the simple fix?

[cscetbon]

@erikedling any progress on that issue ? Setting the namespace in the provider doesn't even work for me too when trying to invoke a function, I have to use the default namespace only

[arditdine]

I had the same issue but I noticed that when you create a new serverless project with the command: serverless create --template kubeless-nodejs --path new-project works fine, you can deploy in every namespace and can invoke the functions. If you check in package.json it uses serverless-kubeless v0.4.0. I've tested and everything works fine up to version 0.6.0 In the new versions of serverless-kubeless it doesn't work. The only difference I found between versions was that in invoke.js on line 115 the function was changed from core.services.get => core.ns.services.get If you remove ns it works fine again.

I've made a PR for this #228

[cscetbon]

@arditdine interesting ! I’ll have to try it

[arditdine]

@andresmgot I think it's safe to close this right?

[andresmgot]

Indeed, thanks @arditdine! This has been fixed in 0.11.1.