Tanzu Framework provides a set of building blocks to build atop of the Tanzu platform and leverages Carvel packaging and plugins to provide users with a much stronger, more integrated experience than the loose coupling and stand-alone commands of the previous generation of tools.
Describe the feature request
This is one in a series of proposed components that cover common interactions in the CLI to save plugin authors from having to duplicate efforts.
The use of a shared set of components will also contribute to the consistency of interactions and interfaces across the plugins.
This feature request is intended to capture the idea and the start of an open discussion, and not necessarily be implemented as described here. The overall goal is, as much as possible, to have a library of shared components for common interactions.
Logging component
Log format is likely a server-side concern, but it would be nice to have a common way for users to to interact with logs across plugins
Would be good to have a consistent way to specifying verbosity (There may be framework we can use for this)
The Tanzu CLI currently has verbosity settings from 1-10, which seems like a lot, (Is this coming from a library we are using?)
Might we reduce it to a smaller set, for example: syslog standard of info/warn/err/debug (default to info)
Open Questions
Is there a standard level of verbosity we advise authors to default to?
Check: What is the community doing? We should match.
Describe alternatives you've considered
Pickup an existing framework
Plugin authors implement the behavior for their plugin, using the style guide as guidance.
Affected product area (please put an X in all that apply)
[ ] APIs
[ ] Addons
[x] CLI
[ ] Docs
[ ] Installation
[x] Plugin
[ ] Security
[ ] Test and Release
[x] User Experience
Additional context
Collated Context
Context from 2021-03-25 00:02:17
User: Anuj2512
Would be good to have a consistent way to specifying verbosity (There may be framework we can use for this)
The Tanzu CLI currently has verbosity settings from 1-10, which seems like a lot, (Is this coming from a library we are using?)
Might we reduce it to a smaller set, for example: syslog standard of info/warn/err/debug (default to info)
Also, the logging library that has been implemented in TKG CLI is more customized to handle other cases where we want to send logs to UI if required, so the developer doesn't have to write any extra logic to send management-cluster creation logs to the UI.
Describe the feature request This is one in a series of proposed components that cover common interactions in the CLI to save plugin authors from having to duplicate efforts. The use of a shared set of components will also contribute to the consistency of interactions and interfaces across the plugins. This feature request is intended to capture the idea and the start of an open discussion, and not necessarily be implemented as described here. The overall goal is, as much as possible, to have a library of shared components for common interactions.
Logging component
Log format is likely a server-side concern, but it would be nice to have a common way for users to to interact with logs across plugins
Would be good to have a consistent way to specifying verbosity (There may be framework we can use for this)
The Tanzu CLI currently has verbosity settings from 1-10, which seems like a lot, (Is this coming from a library we are using?)
Might we reduce it to a smaller set, for example: syslog standard of info/warn/err/debug (default to info)
Open Questions
Is there a standard level of verbosity we advise authors to default to? Check: What is the community doing? We should match.
Describe alternatives you've considered Pickup an existing framework Plugin authors implement the behavior for their plugin, using the style guide as guidance.
Affected product area (please put an X in all that apply)
[ ] APIs [ ] Addons [x] CLI [ ] Docs [ ] Installation [x] Plugin [ ] Security [ ] Test and Release [x] User Experience
Additional context
Collated Context
Context from 2021-03-25 00:02:17 User: Anuj2512
Also, the logging library that has been implemented in TKG CLI is more customized to handle other cases where we want to send logs to UI if required, so the developer doesn't have to write any extra logic to send management-cluster creation logs to the UI.
Some of the answers regarding the questions mentioned above are in the FAQ of this repo https://github.com/go-logr/logr#faq