pmcq
commented
4 years ago make sense. i do wonder if it's not worth renaming stdout to something like
combined_stdout_stderr, but overall, I don't see it blocking this PR.
Yeah I think we'll have to seriously reconsider io handling a bit more broadly and will try to make note of this in the meantime
… reported back through the api-server for backward-compatibility.
Confirmed in test environment that messages from stderr are now being returned as expected, and also that in our current environment messages from stderr/stdout might be interleaved in an arbitrary way if all messages are logged right after each other. Trying to do something like adding a timestamp to the messages in the list and sorting would also have no impact since the timestamp would be based on when the stdout/stderr watcher executes which is already arbitrary.
Anyway, clearly this is not an ideal situation since stdout/stderr should get reported back in a more reasonable or consistent way, however this is consistent with our current system and we need to approach stderr handling a bit more holistically than I think would make sense for this PR, e.g. the expectation of what values we read from stderr vs stdout to populate which fields in a response are not clearly defined so for now we just try to maintain whatever the current system is doing.