Simplified printing for live apply

[justinsb]

We aim to create one column that shows the current activity, to give users a single column to watch.

[justinsb]

I attached a screenshot so people can follow along:

A few things that I intend to tackle moving forwards:

• I don't know if it makes sense to combine name + kind, but keep namespace separate. It looks a little weird on cluster-scoped objects. But TBD!
• We aren't capturing errors from apply
• I'd like to come up with a better "all is well" state than Current. AppliedAndHealthy or just Done, maybe. I probably also wouldn't print the conditions in this case either.
• Generally I want to de-emphasize healthy/done objects, and draw more attention to the failures (and "medium" attention to things that are in-progress).
• When things fail, we have more room now, but we probably still don't have enough room. I think we may need to dedicate multiple rows to failed objects, and/or maybe on a Control-C we print the full errors for failed objects.

[droot]

I attached a screenshot so people can follow along:

A few things that I intend to tackle moving forwards:

• I don't know if it makes sense to combine name + kind, but keep namespace separate. It looks a little weird on cluster-scoped objects. But TBD!
• We aren't capturing errors from apply
• I'd like to come up with a better "all is well" state than Current. AppliedAndHealthy or just Done, maybe. I probably also wouldn't print the conditions in this case either.
• Generally I want to de-emphasize healthy/done objects, and draw more attention to the failures (and "medium" attention to things that are in-progress).
• When things fail, we have more room now, but we probably still don't have enough room. I think we may need to dedicate multiple rows to failed objects, and/or maybe on a Control-C we print the full errors for failed objects.

Thanks, the list looks promising. I am surprised about we aren't capturing errors from Apply, really ?

[justinsb]

I am surprised about we aren't capturing errors from Apply, really ?

We are capturing that there was an error, but not what the error was. So KCC immutable fields, for example, are hard to understand. But a fix is coming next :-)

[mortent]

It looks like this removes the message column. How do we provide more information to users about why a resource isn't successfully reconciling? While ideally we should have everything based off of conditions, that isn't actually the case.

It also seems like this removes the tree view which includes child resources. Don't we want to have that? It does have some overhead in terms of fetching the state of those resources, but it is pretty useful when things goes wrong.

It looks like the action column is also removed. I think that can be pretty useful for users to know whether resources are being applied or pruned.

[droot]

I am surprised about we aren't capturing errors from Apply, really ?

We are capturing that there was an error, but not what the error was. So KCC immutable fields, for example, are hard to understand. But a fix is coming next :-)

Got it. Thanks

[justinsb]

@mortent We aren't going to remove any useful information. Rather the intent is to combine all the "status" columns into one column, because what I've observed is that often only one column is showing important information at a time (or one is showing the status and the other is showing the details). By doing so, we help the user (well, me) understand what's going on, and we get a little more space to play on the screen.

[mortent]

The issue that the error is not being printed seems like something we should fix in the regular command as well as in the alpha command.