openwhisk-cli

openwhisk-cli copied to clipboard

@rabbah commented on Thu Nov 10 2016

I've experience several instances where a schema change in the controller must be reflected in the CLI to properly render the expected output on the command line because the current CLI implementation encodes the types too strictly and unnecessarily - in every case I've encountered so far where I've made a schema change to add or remove a field, the CLI would have been just fine if it treated the response from the controller opaquely.

We should refactor the API respond handling in the CLI so that it uses more generic JSON object interface rather than strict types that just get in the way.

I've also found several instances where the CLI is not in sync with the controller (Evidenced by several defects I've opened for these in recent days) and the CLI injects properties that should not exist (and hence confusing).

---

@ioana-blue commented on Thu Nov 10 2016

I was bit by this as well and it's not fun. In fact, if I hadn't checked with RR, I would have wasted a lot of time on chasing a "bug" in my code, while it was really a schema change for activations which is not reflected in the cli.

@rabbah @dubeejw @mdeuser what's left for this issue? From I understand from @mdeuser goLang dealing with JSON is not flexible, so it always needs to be a hardish code schema/sync

@csantanapr - it's not pretty, but i believe it's possible to use type reflection and the generic Go interface to crawl through an arbitrary json string. after some more hunting, i've found some arbitrary json parsing packages that might do the trick

• https://github.com/Jeffail/gabs
• https://github.com/antonholmquist/jason

Good find @mdeuser that’s why I didn’t close the issue

This is more than technical debt - it's a bug. The CLI is often injecting fields and assigning them values when they don't exist in the API response and leads to confusion (It's confused me many times).