CLI JSON output

[lkingland]

Some of the commands support specifying JSON output; it would be nice to have all commands support this flag.

[lance]

I see that describe has YAML/JSON/XML output options, but it seems that may be the only command that does. How do you see this working for other commands?

• create optionally spits out YAML for the kn Service
• delete not sure about this one
• list YAML of the deployed Service(s)
• run ??
• update spits out YAML for the updated Service

Am I missing anything?

[lkingland]

This issue is with reference to the output as a whole, most importantly log statements. I was hoping we could create a consistent flag which supports, at least "json", and is essentially saying "output human readable or machine readable".

In the case of describe, the YAML and XML options make sense in addition to JSON.

For create, I was thinking setting this flag would disable the fancy progress indicator (essentially running in non-interactive mode), and prints the sequential logs in the same way as it does in non-interactive mode, but using structured logs; some json parseable string. This is both for creating queryable logs from automated tasks, or for users of jq or jid.

Essentially, someone just getting started would want to see a friendly progress indicator which does not clutter up their terminal with log-spew that will overwhelm them. This is the default on faas create ...

An intermediate user might want to script the faas commands run, in which case the binary actually detects if it is running in this manner, and just prints sequential, simple logs instead of doing the control characters which enable the progress bar.

An advanced user might both want to script the faas command's usage, and export structured logs to Elasticsearch for post-processing. Format TBD.

delete would also simply swap the logger with a structured log. list would be a slightly more complex object, and include options for YAML and XML (though I am not an enthusiastic supporter of either).

update would also simply export logs in a structured format.

run is a little bit of a special case, as it delegates... We could respect this flag in faas itself, perhaps setting a well-known environment variable which can optionally be respected by the Function author to choose the way they treat STDOUT and STDERR?

In general, I wouldn't want to print out any Kubernetes-specific objects, but rather the minimum data necessary to encapsulate the meat of the object, or message confirming the success/failure of the task. This way we have a high liklihood of being able to make the output similar (if not identical) on various providers.

Sorry @lance; my initial issue was pretty light on substance!

[matejvasek]

@lkingland list currently returns only names. If we wanted return more, what fields are we interested in?

[lkingland]

It's my opinion that we should be seeking the simplest possible functional case at this time, and only add more as specific use-cases require them. The minimum necessary information to subscribe to an event is its unique identifier, thus the minimum necessary information back out of the system would be those same unique identifiers returned. If we want to add more information; perhaps augmented with fields that are platform-specific, I would see that as a GET request for more information about the subscription of that ID.
so POSTing a name to localhost:1111/subscriptions would append the name to the list. The list would then be returned by GET, with additional information below the named event. Something like:

GET localhost:1111/subscriptions
[ "newsletter-signups" ]

GET localhost:1111/subscriptions/newsletter-signups
{ "name": "newsletter-signups",
.... // Other fields lazily added here _only as required_ to fulfill specifically requested use-cases
}

By keeping ourselves so simple as to be nearly an oversimplification, I am hoping we can prevent from painting ourselves into a corner unnecessarily.
I may indeed be missing something here, so please let me know if there are other fields than the event's name which are required to implement the basic pub/sub flow!

[matejvasek]

@lkingland by list here I meant list of deployed functions/ksvcs not subscriptions.

[lkingland]

OK, I see that's for the listing of deployed Functions. I'd say the same general suggestion applies. Just return a list of the names, and then one can get more information about a given service with GET for that specific service by name /functions/www.example.com

[lkingland]

This is complete. Implemented by @matejvasek in #67 and slightly tweaked to have format functions consolidated with the describe command in #79 . Still outstanding is the issue of having structured logging such that all output is of the explicit type, but if we need that, we can save that for a future discussion/info.