search

signalfx / maestro-ng

Orchestration of Docker-based, multi-host environments
https://signalfx.com
Apache License 2.0
685 stars 83 forks source link

output truncated and confusing when more containers then lines on terminal #168

Open iangkent opened 8 years ago

iangkent commented 8 years ago

We have a large scale deployment with 100 containers. When we run the status command the output is truncated to the number of lines in terminal window. This is confusing our deployment operators. Is there a way we can page though list?

zsuzhengdu commented 7 years ago

Terminal output is truncated by terminal.

How to repro.

Define a service with number of instances is bigger than echo $LINES, number of lines of visible terminal. E.g., 27 instances status update is expected in a terminal with number of lines 10.

The problem might be caused by moving cursor down and up in https://github.com/signalfx/maestro-ng/blob/master/maestro/termoutput.py#L131. After moving the cursor down, because of the number of rows/lines of current visible terminal is less than the expected number of lines of output, the cursor could not be moved back to original location when _lines (https://github.com/signalfx/maestro-ng/blob/master/maestro/termoutput.py#L124) is bigger than echo $LINES, but to location (0, 0) of current visible terminal. Therefore, only first $LINES of expected output is visible and the expected output seems truncated. When scrolling up, empty lines are shown, which is caused by moving cursor down. Example as below

  #  INSTANCE                                SERVICE              SHIP                                     CONTAINER                  STATUS

  1. busybox1                                busybox              machine1                                 checking...
  2. ldap1                                   ldap                 machine                                  checking...
  3. mod_cluster                             mod_cluster          machine1                                 checking...
  4. zookeeper1                              zookeeper            machine                                  checking...
  5. zookeeper_data1                         zookeeper_data       machine                                  checking...
  6. graphite1                               graphite             machine                                  checking...
  7. kafka1                                  kafka                machine                                  checking...
  8. solr1                                   solr                 machine                                  checking...
  9. wildfly-dc1                             wildfly-dc           machine                                  checking...
 10. wildfly-apps2                           wildfly-apps         machine1                                 checking...
 24. collectd6                               collectd             machine                                  checking...
zsuzhengdu commented 7 years ago

As mentioned by @iangkent, it could also be reproduced by expecting of showing status of 100 container instances in a terminal with number of lines less than 100. However, all 100 expected containers updates are shown when the number of lines of current visible terminal is bigger than 100, which allows the cursor moved up back to original location/position.

mpetazzoni commented 7 years ago

We have the same problem at SignalFx. I need to find a good solution for this. It's virtually impossible to show an output that updates in-place if it takes more lines that the terminal. I could limit the display to only the last N, but then you don't see everything and it might be confusing too. Thoughts? How would you (the users!) would like this to behave?

zsuzhengdu commented 7 years ago

Thanks for the prompt reply!

Limiting the display to only show the last N or first N (like command ‘top’) threading output might be also confusing. Users may would like to be hinted or acknowledged when there are more lines going to be printed out to terminal and paging the output would be more likely to be accepted. Support to dynamic output scaling basing on the terminal size when terminal was resized by user would be a perfect fix.

Personally, I have tried to use curses to init a new screen to page the output if line number of potential output is bigger than echo $LINES of current terminal. (NOTE: The initiated screen line number is same as (or depends on) the line number of current visible screen.) Users get notified and paging is allowed (Thread level). Signal ‘SIGCONT’ and ‘SIGWINCH’ should be also handled in case of terminal resizing (Process Level). Regarding implementation, I definitely would like to hear expert's advice.

Similar issue has been raised against compose https://github.com/docker/compose/issues/4124