|
| 1 | +=============== |
| 2 | +Command Options |
| 3 | +=============== |
| 4 | + |
| 5 | +OpenStackClient commands all have a set of zero or more options unique to |
| 6 | +the command, however there are of course ways in which these options are |
| 7 | +common and consistent across all of the commands that include them. |
| 8 | + |
| 9 | +These are the set of guidelines for OSC developers that help keep the |
| 10 | +interface and commands consistent. |
| 11 | + |
| 12 | +In some cases (like the boolean variables below) we use the same pattern |
| 13 | +for defining and using options in all situations. The alternative of only |
| 14 | +using it when necessary leads to errors when copy-n-paste is used for a |
| 15 | +new command without understanding why or why not that instance is correct. |
| 16 | + |
| 17 | +Boolean Options |
| 18 | +=============== |
| 19 | + |
| 20 | +Boolean options for any command that sets a resource state, such as 'enabled' |
| 21 | +or 'public', shall always have both positive and negative options defined. |
| 22 | +The names of those options shall either be a naturally occuring pair of |
| 23 | +words (in English) or a positive option and a negative option with `no-` |
| 24 | +prepended (such as in the traditional GNU option usage) like `--share` and |
| 25 | +`--no-share`. |
| 26 | + |
| 27 | +In order to handle those APIs that behave differently when a field is set to |
| 28 | +`None` and when the field is not present in a passed argument list or dict, |
| 29 | +each of the boolean options shall set its own variable to `True` as part of |
| 30 | +a mutiually exclusive group, rather than the more common configuration of setting a |
| 31 | +single destination variable `True` or `False` directly. This allows us to |
| 32 | +detect the situation when neither option is present (both variables will be |
| 33 | +`False`) and act accordingly for those APIs where this matters. |
| 34 | + |
| 35 | +This also requires that each of the boolean values be tested in the |
| 36 | +`take_action()` method to correctly set (or not) the underlying API field |
| 37 | +values. |
| 38 | + |
| 39 | +.. option:: --enable |
| 40 | + |
| 41 | + Enable <resource> (default) |
| 42 | + |
| 43 | +.. option:: --disable |
| 44 | + |
| 45 | + Disable <resource> |
| 46 | + |
| 47 | +Implementation |
| 48 | +~~~~~~~~~~~~~~ |
| 49 | + |
| 50 | +The parser declaration should look like this:: |
| 51 | + |
| 52 | +.. code-block: python |
| 53 | +
|
| 54 | + enable_group = parser.add_mutually_exclusive_group() |
| 55 | + enable_group.add_argument( |
| 56 | + '--enable', |
| 57 | + action='store_true', |
| 58 | + help=_('Enable <resource> (default)'), |
| 59 | + ) |
| 60 | + enable_group.add_argument( |
| 61 | + '--disable', |
| 62 | + action='store_true', |
| 63 | + help=_('Disable <resource>'), |
| 64 | + ) |
| 65 | +
|
| 66 | +An example handler in `take_action()`:: |
| 67 | + |
| 68 | + # This leaves 'enabled' undefined if neither option is present |
| 69 | + if parsed_args.enable: |
| 70 | + kwargs['enabled'] = True |
| 71 | + if parsed_args.disable: |
| 72 | + kwargs['enabled'] = False |
| 73 | + |
| 74 | +List Command Options |
| 75 | +==================== |
| 76 | + |
| 77 | +Additional Fields |
| 78 | +----------------- |
| 79 | + |
| 80 | +Most list commands only return a subset of the available fields by default. |
| 81 | +Additional fields are available with the `--long` option. All list |
| 82 | +commands should allow `--long` even if they return all fields by default. |
| 83 | + |
| 84 | +.. option:: --long |
| 85 | + |
| 86 | + List additional fields in output |
| 87 | + |
| 88 | +Implementation |
| 89 | +~~~~~~~~~~~~~~ |
| 90 | + |
| 91 | +The parser declaration should look like this:: |
| 92 | + |
| 93 | +.. code-block: python |
| 94 | +
|
| 95 | + parser.add_argument( |
| 96 | + '--long', |
| 97 | + action='store_true', |
| 98 | + default=False, |
| 99 | + help='List additional fields in output', |
| 100 | + ) |
| 101 | +
|
| 102 | +Pagination |
| 103 | +---------- |
| 104 | + |
| 105 | +There are many ways to do pagination, some OpenStack APIs support it, some don't. |
| 106 | +OpenStackClient attempts to define a single common way to specify pagination on |
| 107 | +the command line. |
| 108 | + |
| 109 | +.. option:: --marker <marker> |
| 110 | + |
| 111 | + Anchor for paging |
| 112 | + |
| 113 | +.. option:: --limit <limit> |
| 114 | + |
| 115 | + Limit number of <resource> returned (*integer*) |
| 116 | + |
| 117 | +Implementation |
| 118 | +~~~~~~~~~~~~~~ |
| 119 | + |
| 120 | +The parser declaration should look like this:: |
| 121 | + |
| 122 | +.. code-block: python |
| 123 | +
|
| 124 | + parser.add_argument( |
| 125 | + "--marker", |
| 126 | + metavar="<marker>", |
| 127 | + help="Anchor for paging", |
| 128 | + ) |
| 129 | +
|
| 130 | + parser.add_argument( |
| 131 | + "--limit", |
| 132 | + metavar="<limit>", |
| 133 | + type=int, |
| 134 | + help="Limit the number of <resource> returned", |
| 135 | + ) |
0 commit comments