Is there a reason why 'glance index' has a built-in pager?

Asked by Craig Sanders

I'm hacking on the glance command, trying to make the output more useful to me.

I've already got a working --csv output option, for parseable output (although I'm thinking I should make it more generic and allow the user to specify the delimiter - tab, colon, comma, etc) , and now i want to make some changes to the human-readable tabulated output.

What I'd like to know is: is there a good reason why 'glance index' has a built-in pager ("Fetch next page? [Y/n]"), rather than rely on the fact that the user has access to more or less or whatever pager they prefer?

If there isn't a good reason, then i'll feel comfortable just rewriting that _images_index function. Otherwise, I'm not sure yet what I'll do.

The built-in pager, BTW, actually breaks the ability to use more or less, or even redirect output to a file as it sits there waiting for the user to enter Y or N after fetching the first "page" of image data. I should file that as a bug report.

Question information

Language:
English Edit question
Status:
Answered
For:
Glance Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Eoghan Glynn (eglynn) said :
#1

The glance index command support a -f/--force option that results in the image list being un-paged.

Its arguable whether pagination should be the default, but you can acheive what you want most simply with:

  bin/glance index -f

Revision history for this message
Craig Sanders (cas) said :
#2

Thanks, but that doesn't actually answer my question - is there a good reason, or any reason other than "it was only a few extra lines of code to add it", for /usr/bin/glance to do pagination at all?

My purpose is not to learn how to run glance as it is, my purpose is to learn how best to improve it. Partly by adding useful features (like a --csv option for parseable output), and partly by making it work in a similar manner to most other *nix command line tools (i.e. as a small tool, usable in shell scripts and pipes).

If there's a particularly good reason for /usr/bin/glance to do paging itself, then that requires a particular design for the _images_index function. i.e. pretty much what it is now.

If there isn't a good reason, then it would be better to remove the paging altogether and leave that to tools that specialise in that particular job - more and less as obvious examples.

There's also another related issue: '--limit' is a confusing and misleading name for the option as it is currently used. It doesn't limit anything, it controls the page size for pagination. it should either be renamed --page-size, or it should be changed so that it is actually a limit.

My local fork of glance does the latter. Which is why I want to know if there's a good reason for it being the way it is before I spend too much more time going down a dead-end path that has no chance of being accepted upstream.

Revision history for this message
Eoghan Glynn (eglynn) said :
#3

Hi Craig,

I'm not familiar with the exact motivation for enabling glance index pagination by default, as the feature pre-dates my involvement.

However, I don't think it's that unusual for a command likely to produce voluminous output to fire up a pager by default, for example git-diff and git-log work in this way, and similarly the default behaviour can be overridden with git --no-pager.

A couple of differences between git pagination and glance index::

- git uses an external command as opposed to built-in pagination, defaulting to less, but overridable via PAGER or git config

- git detects whether the output is being redirected or piped and avoids paginating automatically in that case

On the latter point, an incremental improvement would be to detect whether the output from glance index is going direct to a terminal and suppress pagination when its being redirected or piped, e.g.:

diff --git a/bin/glance b/bin/glance
index 9eb68ae..fe273f1 100755
--- a/bin/glance
+++ b/bin/glance
@@ -516,7 +516,9 @@ def _images_index(client, filters, limit, print_header=False
                                     image['container_format'],
                                     image['size'])

- if not options.force and len(images) == limit and \
+ suppress_pagination = options.force or not sys.stdout.isatty()
+
+ if not suppress_pagination and len(images) == limit and \
        not user_confirm("Fetch next page?", True):
         return SUCCESS

The other thing to consider is than a new glance CLI is being prepared in:

  https://github.com/openstack/python-glanceclient

to better align glance with the other openstack projects. This new client will eventual displace the current glance CLI. The new client doesn't paginate by default right now, though it may do so in the future.

It would probably be best to concentrate your efforts on this new client, for example to implement your --csv option against it.

Revision history for this message
Craig Sanders (cas) said :
#4

OK, it sounds like there isn't any particular reason for it, someone just decided to include the feature.

RE: your patch: yep, i already had something similar:

- parser.add_option('-f', '--force', dest="force",
- default=False, action="store_true",
+ parser.add_option('-f', '--force', dest="force", metavar="FORCE",
+ default=not os.isatty(1), action="store_true",
                       help="Prevent select actions from requesting "
- "user confirmation")
+ "user confirmation. Default is False when stdout

and then i got around to questioning why glance even had built-in paging.

I'll take your advice on the new python-glanceclient tool, I wasn't aware of it. But i'm going to have to work on both the old and the new at the moment....we're still in the planning and testing stages of upgrading from diablo to essex so it'll be a long time before the new python-glanceclient is available on our production systems.

I really hope the new tool doesn't get a built-in pager. that contradicts the unix "small-tools" philosophy that a tool should focus on one thing (e.g. VM image management, including lists, details, upload, delete etc) and only one thing, but do it extremely well. leave other tasks (e.g. output paging) to other specialised tools. re-implementing a bare-bones pager instead of just relying on less or more or whatever does no-one any favours.

thanks,

craig

Can you help with this problem?

Provide an answer of your own, or ask Craig Sanders for more information if necessary.

To post a message you must log in.