136 lines
		
	
	
		
			3.9 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
			
		
		
	
	
			136 lines
		
	
	
		
			3.9 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
| ===============
 | |
| Command Options
 | |
| ===============
 | |
| 
 | |
| OpenStackClient commands all have a set of zero or more options unique to
 | |
| the command, however there are of course ways in which these options are
 | |
| common and consistent across all of the commands that include them.
 | |
| 
 | |
| These are the set of guidelines for OSC developers that help keep the
 | |
| interface and commands consistent.
 | |
| 
 | |
| In some cases (like the boolean variables below) we use the same pattern
 | |
| for defining and using options in all situations.  The alternative of only
 | |
| using it when necessary leads to errors when copy-n-paste is used for a
 | |
| new command without understanding why or why not that instance is correct.
 | |
| 
 | |
| Boolean Options
 | |
| ===============
 | |
| 
 | |
| Boolean options for any command that sets a resource state, such as 'enabled'
 | |
| or 'public', shall always have both positive and negative options defined.
 | |
| The names of those options shall either be a naturally occurring pair of
 | |
| words (in English) or a positive option and a negative option with `no-`
 | |
| prepended (such as in the traditional GNU option usage) like `--share` and
 | |
| `--no-share`.
 | |
| 
 | |
| In order to handle those APIs that behave differently when a field is set to
 | |
| `None` and when the field is not present in a passed argument list or dict,
 | |
| each of the boolean options shall set its own variable to `True` as part of
 | |
| a mutiually exclusive group, rather than the more common configuration of setting a
 | |
| single destination variable `True` or `False` directly.  This allows us to
 | |
| detect the situation when neither option is present (both variables will be
 | |
| `False`) and act accordingly for those APIs where this matters.
 | |
| 
 | |
| This also requires that each of the boolean values be tested in the
 | |
| `take_action()` method to correctly set (or not) the underlying API field
 | |
| values.
 | |
| 
 | |
| .. option:: --enable
 | |
| 
 | |
|     Enable <resource> (default)
 | |
| 
 | |
| .. option:: --disable
 | |
| 
 | |
|     Disable <resource>
 | |
| 
 | |
| Implementation
 | |
| ~~~~~~~~~~~~~~
 | |
| 
 | |
| The parser declaration should look like this::
 | |
| 
 | |
| .. code-block: python
 | |
| 
 | |
|         enable_group = parser.add_mutually_exclusive_group()
 | |
|         enable_group.add_argument(
 | |
|             '--enable',
 | |
|             action='store_true',
 | |
|             help=_('Enable <resource> (default)'),
 | |
|         )
 | |
|         enable_group.add_argument(
 | |
|             '--disable',
 | |
|             action='store_true',
 | |
|             help=_('Disable <resource>'),
 | |
|         )
 | |
| 
 | |
| An example handler in `take_action()`::
 | |
| 
 | |
|         # This leaves 'enabled' undefined if neither option is present
 | |
|         if parsed_args.enable:
 | |
|             kwargs['enabled'] = True
 | |
|         if parsed_args.disable:
 | |
|             kwargs['enabled'] = False
 | |
| 
 | |
| List Command Options
 | |
| ====================
 | |
| 
 | |
| Additional Fields
 | |
| -----------------
 | |
| 
 | |
| Most list commands only return a subset of the available fields by default.
 | |
| Additional fields are available with the `--long` option.  All list
 | |
| commands should allow `--long` even if they return all fields by default.
 | |
| 
 | |
| .. option:: --long
 | |
| 
 | |
|     List additional fields in output
 | |
| 
 | |
| Implementation
 | |
| ~~~~~~~~~~~~~~
 | |
| 
 | |
| The parser declaration should look like this::
 | |
| 
 | |
| .. code-block: python
 | |
| 
 | |
|         parser.add_argument(
 | |
|             '--long',
 | |
|             action='store_true',
 | |
|             default=False,
 | |
|             help='List additional fields in output',
 | |
|         )
 | |
| 
 | |
| Pagination
 | |
| ----------
 | |
| 
 | |
| There are many ways to do pagination, some OpenStack APIs support it, some don't.
 | |
| OpenStackClient attempts to define a single common way to specify pagination on
 | |
| the command line.
 | |
| 
 | |
| .. option:: --marker <marker>
 | |
| 
 | |
|     Anchor for paging
 | |
| 
 | |
| .. option:: --limit <limit>
 | |
| 
 | |
|     Limit number of <resource> returned (*integer*)
 | |
| 
 | |
| Implementation
 | |
| ~~~~~~~~~~~~~~
 | |
| 
 | |
| The parser declaration should look like this::
 | |
| 
 | |
| .. code-block: python
 | |
| 
 | |
|         parser.add_argument(
 | |
|             "--marker",
 | |
|             metavar="<marker>",
 | |
|             help="Anchor for paging",
 | |
|         )
 | |
| 
 | |
|         parser.add_argument(
 | |
|             "--limit",
 | |
|             metavar="<limit>",
 | |
|             type=int,
 | |
|             help="Limit the number of <resource> returned",
 | |
|         )
 | 
