Do you want to render ANSI in Zuul console?
At this moment Zuul web interfaces displays output of commands as raw, so any ANSI terminal output will display ugly artifacts. I tried enabling ANSI about half a year ago but even after providing two different implementations, I was not able to popularize it enough. As this is a UX related feature, I think would like more appropriate to ask for feedback from openstack-discuss, likely the biggest consumer of zuul web interface. Please comment/+/- on review below even if you are not a zuul core. At least it should show if this is a desired feature to have or not: https://review.opendev.org/#/c/739444/ ✅ This review also includes a screenshot that shows how the rendering looks (an alternative for using the sitepreview) Thanks Sorin Sbarnea
On Thu, Aug 27, 2020, at 1:11 AM, Sorin Sbarnea wrote:
At this moment Zuul web interfaces displays output of commands as raw, so any ANSI terminal output will display ugly artifacts.
I tried enabling ANSI about half a year ago but even after providing two different implementations, I was not able to popularize it enough.
As this is a UX related feature, I think would like more appropriate to ask for feedback from openstack-discuss, likely the biggest consumer of zuul web interface.
Please comment/+/- on review below even if you are not a zuul core. At least it should show if this is a desired feature to have or not:
Without my Zuul hat on but with my "I debug a lot of openstack jobs" hat I would prefer we remove ansi color controls from our log files entirely. They make using grep and other machine processing tools more difficult. I find the utility of grep, ^F, elasticsearch, and the log level severity filtering far more useful than scrolling and looking for colors that may be arbitrarily applied by the source.
https://review.opendev.org/#/c/739444/ ✅
This review also includes a screenshot that shows how the rendering looks (an alternative for using the sitepreview)
Thanks Sorin Sbarnea
On Thu, 2020-08-27 at 08:37 -0700, Clark Boylan wrote:
On Thu, Aug 27, 2020, at 1:11 AM, Sorin Sbarnea wrote:
At this moment Zuul web interfaces displays output of commands as raw, so any ANSI terminal output will display ugly artifacts.
I tried enabling ANSI about half a year ago but even after providing two different implementations, I was not able to popularize it enough.
As this is a UX related feature, I think would like more appropriate to ask for feedback from openstack-discuss, likely the biggest consumer of zuul web interface.
Please comment/+/- on review below even if you are not a zuul core. At least it should show if this is a desired feature to have or not:
Without my Zuul hat on but with my "I debug a lot of openstack jobs" hat I would prefer we remove ansi color controls from our log files entirely. They make using grep and other machine processing tools more difficult. I find the utility of grep, ^F, elasticsearch, and the log level severity filtering far more useful than scrolling and looking for colors that may be arbitrarily applied by the source. if we can remove them form the logs but use a javascpit lib in the viewer to still highlight thing that might be the best of both worlds i do fine the syntax hyilighign nice but we dont need color codes to do that.
https://review.opendev.org/#/c/739444/ ✅
This review also includes a screenshot that shows how the rendering looks (an alternative for using the sitepreview)
Thanks Sorin Sbarnea
On Thu, 2020-08-27 at 17:24 +0100, Sean Mooney wrote:
On Thu, 2020-08-27 at 08:37 -0700, Clark Boylan wrote:
On Thu, Aug 27, 2020, at 1:11 AM, Sorin Sbarnea wrote:
At this moment Zuul web interfaces displays output of commands as raw, so any ANSI terminal output will display ugly artifacts.
I tried enabling ANSI about half a year ago but even after providing two different implementations, I was not able to popularize it enough.
As this is a UX related feature, I think would like more appropriate to ask for feedback from openstack-discuss, likely the biggest consumer of zuul web interface.
Please comment/+/- on review below even if you are not a zuul core. At least it should show if this is a desired feature to have or not:
Without my Zuul hat on but with my "I debug a lot of openstack jobs" hat I would prefer we remove ansi color controls from our log files entirely. They make using grep and other machine processing tools more difficult. I find the utility of grep, ^F, elasticsearch, and the log level severity filtering far more useful than scrolling and looking for colors that may be arbitrarily applied by the source.
if we can remove them form the logs but use a javascpit lib in the viewer to still highlight thing that might be the best of both worlds i do fine the syntax hyilighign nice but we dont need color codes to do that. i ment to say i have had some success with https://highlightjs.org/ before for that use case mainly in blogs but it might be a solution.
https://review.opendev.org/#/c/739444/ ✅
This review also includes a screenshot that shows how the rendering looks (an alternative for using the sitepreview)
Thanks Sorin Sbarnea
This does not make much sense to me as it sounds as: Lets convert all the images to B&W because it takes less space on disk and tell user to use JS based AI to recolor to them. Displaying ANSI does not mean colorize my logs, has nothing to do with it. Displaying ANSI is about respecting the output produced by the executed tools. Zuul should respect the output received on stderr/stdout and display it like a console/ terminal. If the job author decides to use ANSI or not is up to them. Still, Zuul itself as product should just render ANSI content, mainly because I do not see any use-case where someone would want to render that text as RAW, as we all know ANSI escapes do not add any value to the user. Still, if the ability to display raw text, without ansi conversion is a real need, I could spend few more hours to implement it and add a preference option. Still, think twice before asking for a feature that adds some code complexity and may not prove to be of real practical use. We all know that the raw text is still available inside the big json file in case someone has doubs regarding what was rendered may be wrong.
On 27 Aug 2020, at 17:24, Sean Mooney <smooney@redhat.com> wrote:
On Thu, 2020-08-27 at 08:37 -0700, Clark Boylan wrote:
On Thu, Aug 27, 2020, at 1:11 AM, Sorin Sbarnea wrote:
At this moment Zuul web interfaces displays output of commands as raw, so any ANSI terminal output will display ugly artifacts.
I tried enabling ANSI about half a year ago but even after providing two different implementations, I was not able to popularize it enough.
As this is a UX related feature, I think would like more appropriate to ask for feedback from openstack-discuss, likely the biggest consumer of zuul web interface.
Please comment/+/- on review below even if you are not a zuul core. At least it should show if this is a desired feature to have or not:
Without my Zuul hat on but with my "I debug a lot of openstack jobs" hat I would prefer we remove ansi color controls from our log files entirely. They make using grep and other machine processing tools more difficult. I find the utility of grep, ^F, elasticsearch, and the log level severity filtering far more useful than scrolling and looking for colors that may be arbitrarily applied by the source. if we can remove them form the logs but use a javascpit lib in the viewer to still highlight thing that might be the best of both worlds i do fine the syntax hyilighign nice but we dont need color codes to do that.
https://review.opendev.org/#/c/739444/ <https://review.opendev.org/#/c/739444/> ✅
This review also includes a screenshot that shows how the rendering looks (an alternative for using the sitepreview)
Thanks Sorin Sbarnea
On Thu, Aug 27, 2020, at 1:56 PM, Sorin Sbarnea wrote:
This does not make much sense to me as it sounds as: Lets convert all the images to B&W because it takes less space on disk and tell user to use JS based AI to recolor to them.
Displaying ANSI does not mean colorize my logs, has nothing to do with it.
Displaying ANSI is about respecting the output produced by the executed tools.
Zuul should respect the output received on stderr/stdout and display it like a console/ terminal. If the job author decides to use ANSI or not is up to them.
You asked if OpenStack would use/like to use such a feature. I'm suggesting a better option for OpenStack is to avoid adding a bunch of control codes to logs.
Still, Zuul itself as product should just render ANSI content, mainly because I do not see any use-case where someone would want to render that text as RAW, as we all know ANSI escapes do not add any value to the user.
Still, if the ability to display raw text, without ansi conversion is a real need, I could spend few more hours to implement it and add a preference option. Still, think twice before asking for a feature that adds some code complexity and may not prove to be of real practical use. We all know that the raw text is still available inside the big json file in case someone has doubs regarding what was rendered may be wrong.
On 27 Aug 2020, at 17:24, Sean Mooney <smooney@redhat.com> wrote:
On Thu, 2020-08-27 at 08:37 -0700, Clark Boylan wrote:
On Thu, Aug 27, 2020, at 1:11 AM, Sorin Sbarnea wrote:
At this moment Zuul web interfaces displays output of commands as raw, so any ANSI terminal output will display ugly artifacts.
I tried enabling ANSI about half a year ago but even after providing two different implementations, I was not able to popularize it enough.
As this is a UX related feature, I think would like more appropriate to ask for feedback from openstack-discuss, likely the biggest consumer of zuul web interface.
Please comment/+/- on review below even if you are not a zuul core. At least it should show if this is a desired feature to have or not:
Without my Zuul hat on but with my "I debug a lot of openstack jobs" hat I would prefer we remove ansi color controls from our log files entirely. They make using grep and other machine processing tools more difficult. I find the utility of grep, ^F, elasticsearch, and the log level severity filtering far more useful than scrolling and looking for colors that may be arbitrarily applied by the source. if we can remove them form the logs but use a javascpit lib in the viewer to still highlight thing that might be the best of both worlds i do fine the syntax hyilighign nice but we dont need color codes to do that.
https://review.opendev.org/#/c/739444/ ✅
This review also includes a screenshot that shows how the rendering looks (an alternative for using the sitepreview)
Thanks Sorin Sbarnea
participants (3)
-
Clark Boylan
-
Sean Mooney
-
Sorin Sbarnea