Add option to follow the component logs when running spin up

[radu-matei]

When running spin up, you see the Spin logs, and the logs of components are saved in the configured logs directory.

I would like to propose optionally following the component logs in the standard output / error of the Spin process.

[itowlson]

I can take a crack at this, but would like to raise what the UI might look like. A few thoughts (using follow as a sighting shot but that is up for grabs too).

Option 1

• spin up --follow - follows all components

It's terse, but not very selective if you have a lot of components.

Option 2

• spin up --follow comp1 --follow comp2 - follows all specified components

Yes Ivan but what if you really do want to follow all of them what then.

Option 3

• spin up --follow comp1 --follow comp2 - follows those components
• spin up --follow-all - follows all

Plenty of control but phew that's a lotta options to go in the help text.

Option 4

• spin up --follow comp1 --follow comp2 - follows those components
• spin up --follow - follows all

Confusing? Even possible in structopt?

Option 5

• spin up --follow comp1 --follow comp2 - follows those components
• spin up --follow all - follows all

A magic value! Would that be discoverable enough? Could we find one that couldn't clash with a component name and yet would not look weird?

Option N

Something else that is obvious but I haven't thought of yet!

cc @michelleN

[radu-matei]

If it was possible (yay for enum shenanigans?), I would very much like option 4.

[itowlson]

I like that too. I will see if I can bend structopt to my will.

[itowlson]

Looks like log handling is wired up at the trigger/executor level at the moment - the http trigger does various shenanigans to send component logs to files, the redis trigger uses the default stdio and so sends component logs to the console.

I tentatively assume that the desired behaviour after this change is as follows:

• By default, all component writes to stdout/stderr should go to the log directory.
• If a follow flag applies, component writes to stdout/stderr should go to Spin's stdout/stderr.
• Specific executors may assign special meaning to one of the component output streams, such as WAGI does to stdout. So executors should be able to opt out of the default behaviour.

But perhaps we should discuss and confirm? We want the behaviour to be useful to users, and perhaps the above is not right for all trigger types?

[itowlson]

clap/structopt has defeated me for option 4. It seems to have firm views that an argument either takes a value or does not, and should jolly well make up its mind. You can handcraft FromArgMatches to provide smarter parsing, but it still wants a clear indication if the flag itself is to be followed by a value.

I suspect this is because --follow foo would be potentially ambiguous. If it allowed either, should it parse this as --follow with value foo , or --follow without value followed by an (unexpected) positional arg with value foo?

[itowlson]

Worth also considering the embedding scenario - if a consumer wants to embed a Spin trigger but wants to customise where the output goes, should we provide for this and if so how?

[radu-matei]

Hmm, this brings up an interesting question.
My initial assumption was that the --follow log would not prevent Spin from writing the logs to the configured files, but would just follow the files.

Were you thinking that this stop writing the log files and just write to Spin's standard output/error?

Right now, the log directory is configured on the execution context, so it can be changed by an embedder.

[itowlson]

No, I will continue writing everything to the log files with an option to also follow via Spin's stdout/stderr.