Using programmatic cli with multiple namespaces does not work

[rabbah]

Here is a sample program to illustrate the problem. You'll need to test this with a couple of namespaces (and need to generate a couple of login tokens to run this code).

const { runNimCommand} = require('nimbella-cli');

async function getResourceFromToken(token) {
  await runNimCommand('auth/login', [token]);
  const namespace = (await runNimCommand('auth/current')).captured[0]
  const actions = (await runNimCommand('action/list')).table
  console.log(namespace)
  console.log(actions[0].namespace)
}

async function main() {
 await getResourceFromToken(process.env.TOKEN1)
 await getResourceFromToken(process.env.TOKEN2)    
}

main().catch(console.log)

To run this you'll need to use nim auth export for two different namespaces and create two env vars TOKEN1 and TOKEN2, and ensure you have at least one action in each namespace.

expected result

namespace1
namespace1
namespace2
namespace2

actual result

namespace1
namespace1
namespace2
namespace1

If you run this with DEBUG=* you'll see that the second handoff to AIO is wrong and preserved the "whisk identity" from the first login. Look for output like this:

nim:base aio capture intercepts installed
  aio-cli-config reading config: ...
  aio-cli-config reading env variables: runtime.namespace, runtime.apihost, runtime.auth
  aio-cli-plugin-runtime {
  aio-cli-plugin-runtime   apiversion: 'v1',
  aio-cli-plugin-runtime   apihost: 'https://...',
  aio-cli-plugin-runtime   api_key: 'namespace1-only-will-appear-here'
  aio-cli-plugin-runtime }

[rabbah]

The CLI so far has avoided setting WHISK_AUTH explicitly as done in the now merged PR. The whisk auth value ends up https://github.com/adobe/aio-cli-plugin-runtime/blob/156cc025270153f1c9d5929cdd18f6fae0daa6c3/src/RuntimeBaseCommand.js#L33

The AIO config class https://github.com/adobe/aio-lib-core-config/blob/dc1e97e82c20ec1f283c01755b6cad7d469b5b3d/src/Config.js#L51-L59 converts AIO_RUNTIME_AUTH to runtime.auth but it's plausible that the config is not reloaded
https://github.com/adobe/aio-lib-core-config/blob/dc1e97e82c20ec1f283c01755b6cad7d469b5b3d/src/Config.js#L72 and so we might need a deeper fix.

[joshuaauerbachwatson]

IMO this issue should have been filed against the CLI and not the deployer. IMO the title should replace 'deployer' with 'CLI'.

Although the deployer API is imported it is not used in the example. The misbehavior is entirely driven via usage of the CLI library, not the deployer library.

Note that there is no declared dependency of the deployer on AIO. So, it will be difficult to fix this in deployer code.

The accident of history that is confusing us here is that the NimBaseCommand class is located in the deployer package even though it is actually in no way shape or form part of the deployer. It was stuck there some time ago to avoid proliferating packages. There was (at least at the time) a reason why it needed to be moved out of the CLI because of circular dependencies. I think moving it back into the CLI should be explored now that the packaging has changed substantially.

[rabbah]

Thanks for the input @joshuaauerbachwatson. I’ll move the issue and update the code snippet to remove the unused deployer reference.

[joshuaauerbachwatson]

I believe that once upon a time the fixAioCredentials used to force a reload of the AIO config. In order to do this, it needed to have a dependency on aio. When the formal split was instituted with the deployer / CLI separating, and it was decided (dubiously) to move NimBaseCommand over to the deployer side, only because it needed to go somewhere to break a circularity. We did not want the deployer to depend on aio (it otherwise has no need to). So, after a quick assessment down the lines of "hm, we probably don't need this code", (so much for quick assessments) the forced reload of the aio config was removed.

So, my recommendation on fixing this is

1. find the old code. I may or may not be able to help with this because it may predate the open sourcing of the code (I will check).
2. Consider moving NimBaseCommand back to the CLI. Some help from @jthomas might be good here as I think he is most aware of the current component structure and whether or not this would cause an inconvenient circularity. The main issue is that commander-cli needs NimBaseCommand and is itself a dependency of nimbella-cli, so it would need to change to have a dependency on the CLI. That is indeed circular, but since the packaging has been changed to now be completely managed by npm it might be ok.
3. Restore the old code (which should be easy if it has been moved back to the CLI since the CLI has a dependency on aio.

Based on a slack communication from @bhageena I think he is taking responsibility for fixing this. Chandan, if I can't find the old code it will be over to you to find it ... I can probably give some hints.

[joshuaauerbachwatson]

As of Aug 2, 2020 (the oldest relevant commit in this repo), NimBaseCommand indeed had a dependency on aio but did not force a reload of the aio config. I believe it is easy to do this (the config exports a reload() method) and I distinctly recall that there was once code that did it but I think I mis-remembered the motivation for removing that code and the timing of when it was removed. @bhageena up to you to explore further in the past but perhaps that's not even necessary. If it is possible to move NimBaseCommand into the CLI where the dependency on aio can be exploited this should be relatively simple to fix.