cc @garrying

Thanks for bootstrapping this @stmcginnis. Looking forward to the design doc. Here are some ideas that come to mind, worth considering:

1. 💯 to your common on capx-manager holding the key to failures. The logs from these would surely be too noisy to print at default verbosity, however, I think always writing those logs to a bootstrap log file and outputting to the user its available during bootstrap would be extremely high value.

   Creating management cluster in ${INFRASTURCTURE_PROVIDER}
       View bootstrap logs at: ${HOME}/.config/tanzu/tkg/bootstrap-logs/${CLUSTER_NAME}.log

   1. At a higher-verbosity, we just tail those logs to stdout as well.
2. This proposal should break down the bootstrap visibility for management and workload clusters. I forsee these two looking quite different. In other words, i care about different things, like for my workload cluster, I want to understand what TKR was selected, CNI, etc -- not too dissimilar from our new standalone model.

This is great @stmcginnis! The high-level changes resonates with me. Happy to help start the design doc.

RFC open, initially targeting closure on 02/04/2022.

What about something similar to what Linux distros use for installation? A simple screen with one line the describes the current activity and the progress speedometer of that activity. The activity can be expanded to show detail if needed. Does not need to be a GUI, can be ascii/curses/whatever-based

Great idea @DennisFaucher. That's a slightly different approach from what is being proposed here, but I could see that as a great follow on. If we make the updates proposed in the design doc, the UI could read those and update the output like the example you show. Then there could be a "Details" expander or something that would give the full output.

What do you think @miclettej ?

Great idea @DennisFaucher. That's a slightly different approach from what is being proposed here, but I could see that as a great follow on. If we make the updates proposed in the design doc, the UI could read those and update the output like the example you show. Then there could be a "Details" expander or something that would give the full output.

What do you think @miclettej ?

I agree that it's a great suggestion 🎉 , but something we should consider for larger UI work and keep this proposal scoped to giving bootstrap log visibility.

For our future consideration, how do a progress UI like this differ from the kickstart UI?

To Josh's point, we have something like this in the UI but may need to adjust the granularity of steps or filtering of logs. What we know from customers is that they like to know what stage of the deployment they are on, and what is remaining to complete. The step progress on the left was added in response to customer feedback. We can adjust appearance or granularity of steps/messaging to the customer. I think it may be important to continue to show some indication of steps that are completed and not yet completed.

So long team and thanks for all the fish. TCE was great.