Commit ed572319 authored by Aaron Tan's avatar Aaron Tan

Docs for Tower CLI

parent fe4b665b
......@@ -65,3 +65,6 @@ results.xml
# ignore python egg
*.egg-info/
# Sphinx
docs_wip/build/*
# Minimal makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = python -msphinx
SPHINXPROJ = tower_cli
SOURCEDIR = source
BUILDDIR = build
# Put it first so that "make" without argument is like "make help".
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
.PHONY: help Makefile
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
\ No newline at end of file
This README documentation walks you through the process of generating a local doc site for Tower CLI.
Before the actual generating process, make sure you have cloned Tower CLI from github and checked out the right
version tag you want to generate docs from. Also, we use [graphviz](http://www.graphviz.org/) for some graph
generations in doc. Make sure to install graphviz. For example, on OS X:
```
$ brew install graphviz
```
It is always suggested you generate docs in a python virtual environment to prevent any dependency conflicts.
```
$ virtualenv docs
```
And
```
source docs/bin/activate
```
to activate the virtual environment.
In the newly created empty virtual environment, install [sphinx](http://www.sphinx-doc.org/en/stable/), our doc
generating engine.
```
$ sudo pip install sphinx
```
Sphinx walks through an existing python package's source code tree to generate its documentation. so make sure tower
CLI is installed also.
```
$ cd <tower-cli's repo>
$ make install
```
Then, under `docs/` directory, `mkdir build` to create the subdirectory for hosting the local doc site. Also, under
`docs/source`, `mkdir _static` and `mkdir _templates` which are necessary placeholders for doc site compilation.
In Tower CLI, each resource has a lot of fields that need to be grouped and documented as `.rst`-formatted tables.
we provide a script, `docs/source/api_ref/generate_tables.py`, to auto-generate all tables. In order to run the
script, `cd docs/source/api_ref/` and
```
$ python generate_tables.py
```
Now that all documentation source scripts are ready, navigate to `docs/` directory and generate the doc site by
```
$ make html
```
Finally, in web browser, navigate to `file://<wherever tower-cli's repo is>/docs/build/html/index.html` and see
the site for yourself.
Contributor's Guide
===================
All kinds of contributions are more than welcomed. You can help make tower CLI better by reporting bugs, come up
with feature ideas or, even further, help maintainers out by making pull requests. Make sure you follow the rules
below when contributing and you are ready to roll ;)
Bug Reports
-----------
Reporting bugs is highly valuable to us. For flexibility, we do not provide issue templates, but describe the issue
as specific as possible to make it easier and faster for us to hunt down the issue.
- First check existing issues to see if it has already been created, if it has, giving issue description a "thumbs up".
- Mark the issue with 'bug' label.
- Be sure to mention Tower backend version, Tower CLI version and python interpreter version when the bug occurs.
- Copy-paste the detailed usage (code snippet when using as python library and command when using as CLI) and error
message if possible.
Feature Requests
----------------
We welcome all sorts of feature ideas, but note, it may be scheduled for a future release rather than the next one,
please be patient while we process your request. We will ping you on github once the feature is implemented.
- Mark the issue with 'enhancement' label.
Architecture Overview
---------------------
All available Tower CLI resources descent from abstract class ``tower_cli.models.base.BaseResource``, which provides
two fundamental methods, ``read`` and ``write``. ``read`` wraps around a GET method to the specified resource, while
``write`` wraps around a POST or PATCH on condition. Most public resource APIs, like ``create`` or ``list``, are
essentially using a combination of ``read`` and ``write`` to communicate with Tower REST APIs.
.. autoclass:: tower_cli.models.base.BaseResource
:members: read, write
Here is the detailed class hierarchy from ``tower_cli.models.base.BaseResource`` to all specific Tower resources:
.. inheritance-diagram:: tower_cli.models.base tower_cli.models.fields tower_cli.resources.ad_hoc tower_cli.resources.credential_type tower_cli.resources.credential tower_cli.resources.group tower_cli.resources.host tower_cli.resources.instance_group tower_cli.resources.instance tower_cli.resources.inventory_script tower_cli.resources.inventory_source tower_cli.resources.inventory tower_cli.resources.job_template tower_cli.resources.job tower_cli.resources.label tower_cli.resources.node tower_cli.resources.notification_template tower_cli.resources.organization tower_cli.resources.project tower_cli.resources.role tower_cli.resources.schedule tower_cli.resources.setting tower_cli.resources.team tower_cli.resources.unified_job tower_cli.resources.user tower_cli.resources.workflow_job tower_cli.resources.workflow
:parts: 0
Details of each Tower CLI resource module are available under ``tower_cli/resources/``.
Some root-level modules under ``tower_cli/`` folder are of great importance. Specifically, ``api.py`` contains details
of the API client Tower CLI used to make HTTP(S) requests using
`requests <http://docs.python-requests.org/en/master/>`_, and ``conf.py`` is used to define and initialize singleton
setting object ``tower_cli.conf.settings``.
On the other hand, ``tower_cli/cli/`` folder contains code that extends tower_cli from a python library into a full-
fledged command-line interface. We use `click <http://click.pocoo.org/5/>`_ as the CLI engine.
.. inheritance-diagram:: tower_cli.cli.action tower_cli.cli.base tower_cli.cli.resource tower_cli.cli.misc tower_cli.cli.types
:parts: 0
Code Contributions
------------------
Setting up development environment and playing around with Tower CLI is quite straight-forward, here is the usual
development procedure:
1. Branch out a local issue branch from the correct base branch.
2. Create an empty virtual environment.
3. Code.
4. Run ``make install`` to install development Tower CLI and all its dependency to virtual environment.
5. Manually test on your bug fix/feature and modify until manual tests pass.
6. Run ``sudo pip install tox``. Then at the root directory of Tower CLI repository, run ``sudo tox .`` to run flake8
verify and unit test against all supported python versions. Run and modify until all flake8 checks and
unit tests pass.
7. Commit, push to local fork and make pull request targeting the correct base branch.
8. Wait for a maintainer to either approve and merge the pull request, or update pull request according to feedback
comment.
Some points to keep in mind when developing:
- Target the correct branch. Currently we use branch 'v1' to track 3.1.x versions and 'master' to track 3.2.0 and
beyond.
- Consider all API versions. Currently 3.1.x versions are exclusively used for API v1 and 3.2.0 and beyond are
exclusively used for API v2, that means if you fixed a bug for 3.1.8, switch to 3.2.0 and see if the same or
similar bug exists and needs similar fix.
- Consider python 2/3 compatibility, make good use of ``six`` and ``tower_cli.compat``.
- Adhere to the flake8 specifications when developing, the only exception we allow is the maximum line length, which
is 120 characters rather than 79.
- Be pythonic by using meaningful names and clear structures. Make code self-explanatory rather than adding excessive
comments.
- Be test-driven. Although not mandatory, please try keeping test coverage at least the same as before, we appreciate
it if you can increase our test coverage in your pull requests.
Release History
===============
3.1.6 (2017-07-18)
------------------
- Fix a usage compatibility issue for Ansible Tower modules.
3.1.5 (2017-07-12)
------------------
- Major code base file structure refactor. Now all click-related logics are moved to `tower_cli/cli/` directory,
and `exceptions.py` as well as `compat.py` are moved out of utils directory into base directory.
- Categorize help text options for resource action commands (like `update`) to increase readability.
- Behavior change of workflow schema command. Now schema will both create new nodes and delete existing nodes when
needed to make the resulting workflow topology exactly the same as described in schema file.
- Add command `job_template callback` to enable conducting provisioning callback via Tower CLI.
- Add new format option to just echo id.
- Expand some resource fields, including hipchat rooms for notification template and allow_simultaneous for job
templates.
- Lookup related inventory sources with "starts with" logic if its name is not fully qualified.
- Fixed a python 3.5 compatibility issue that causes job monitor traceback.
- Minor typo and help text updates.
3.1.4 (2017-06-07)
------------------
- Support resource copy subcommand.
- Support auth-token-based authentication for Tower CLI requests.
- Support managing workflow roles, labels and notifications via Tower CLI.
- Several fixes on RPM spec file.
- Name change from 'foreman' to 'satellite6' in credential kind choices.
- Fixed a bug where creating job templates with --extra-vars did not work after
3.1.0 upgrade.
- Fixed traceback when launching job with --use-job-endpoint.
- Enhanced json library usage to prevent traceback when using earlier python 2.6
versions.
- Prevent throwing unnecessary warning when reading from global configuration file.
3.1.3 (2017-03-22)
------------------
- Fixed a bug where extra_vars were dropped in some commands.
3.1.2 (2017-03-21)
------------------
- Fixed a bug where global flags are not added to some commands.
3.1.1 (2017-03-13)
------------------
- Fixed a bug which blocks named resources from using runtime configure settings.
- Fixed a bug in 3.1.0 which sometimes causes traceback when `pk` value is given.
3.1.0 (2017-03-09)
------------------
- Improved job monitoring functionality to enable standard out streaming, which
displays real-time job output on command line.
- Added workflow, workflow_job and node endpoints to manipulate workflow graph
and manage workflow job resources. Reflecting workflows feature of Tower 3.1.
- Added settings command to manage Tower settings via Tower CLI. Reflecting
Configure Tower in Tower (CTiT) feature of Tower 3.1.
- Included timeout option to certain unified job template resources. Reflecting
job timeout feature of Tower 3.1.
- Added unicode support to extra_vars and variable types.
- Several minor bug fixes to improve user experience.
3.0.3 (2017-02-07)
------------------
- Expose custom inventory script resource to the user
- Include tests and docs in the release tarball
- Added job template skip_tags prompting support
- Added job template callback support
3.0.2 (2016-12-08)
------------------
- Enable configuring tower-cli via environment variables
3.0.1 (2016-09-22)
------------------
- Added custom SSL certificate support
3.0.0 (2016-08-05)
------------------
- Added text indicator for resource change
- Allow hosts, inventory, and groups to use variables from the command line
and denote a file by starting with "@"
- Added resource role for tower3.0 and permission for previous tower versions
- Added notification templates
- Added labels
- Added description display option
- Added deprecation warnings
- Help text upgrades
- Give indication of "changed" apart from color
- New credential fields to support openstack-v2, networking and azure
- New options for inventory source/group. Add implicit resource inventory
script.
- credential updates (no longer require user/team)
- Added support for system auditors
- projects (do not post to organizations/N/projects)
- prompt-for JT fields + job launch options (allow blank inventory too)
- Update the POST protocol for associate and disassociate actions
- New job launch option for backwards compatibility
- New tower-cli option to display tower-cli version
- Enhanced debug log format (support multi-line debug log)
2.3.2 (2016-07-21)
------------------
- Add RPM specfile and Makefile
- Tower compatibility fixes
- Allow scan JTs as an option for "job_type"
- Add ability to create group as subgroup of another group
- Add YAML output format against JSON and humanized output formats
- Add SSL corner case error handling and suggestion
- Allow resource disassociation with "null"
2.3.1 (2015-12-10)
------------------
- Fixed bug affecting force-on-exists and fail_on_found options
- Changed extra_vars behavior to be more compliant by re-parsing vars,
even when only one source exists
- Fixed group modify bug, avoid sending unwanted fields in modify requests
2.3.0 (2015-10-20)
------------------
- Fixed an issue where the settings file could be world readable
- Added the ability to associate a project with an organization
- Added setting "verify\_ssl" to disallow insecure connections
- Added support for additional cloud credentials
- Exposed additional options for a cloud inventory source
- Combined " launch-time extra\_vars" with " job\_template extra\_vars"
for older Tower versions
- Changed the extra\_vars parameters to align with Ansible parameter
handling
- Added the ability to run ad hoc commands
- Included more detail when displaying job information
- Added an example bash script to demonstrate tower-cli usage
2.1.1 (2015-01-27)
------------------
- Added tests for Python versions 2.6 through 3.4
- Added shields for github README
- Added job\_tags on job launches
- Added option for project local path
2.1.0 (2015-01-21)
------------------
- Added the ability to customize the set of fields used as options for
a resource
- Expanded monitoring capability to include projects and inventory
sources
- Added support for new job\_template job launch endpoint
2.0.2 (2014-10-02)
------------------
- Added ability to set local scope for config file
- Expanded credential resource to allow options for cloud credentials
2.0.1 (2014-07-18)
------------------
- Updated README and error text
2.0.0 (2014-07-15)
------------------
- Pluggable resource architecture built around click
.. _api-ref-conf:
Configuration
=============
In Tower CLI, there are a number of configuration settings available to users. These settings are mostly used to
set up connection details to Tower backend, like hostname of Tower backend and user name/password used for
authentication; some are also used for other purposes, like toggle on/off colored stdout. Here is a list of all
available Tower CLI settings:
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
| **Key** | **Value Type / Value Default** | **Description** |
+==================+=======================================================+============================================================================================================================================================+
| ``color`` | Boolean/'true' | Whether to use colored output for highlighting or not. |
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
|``format`` | String with options ('human', 'json', 'yaml')/'human' | Output format. The "human" format is intended for humans reading output on the CLI; the "json" and "yaml" formats provide more data. [CLI use only] |
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
|``host`` | String/'127.0.0.1' | The location of the Ansible Tower host. HTTPS is assumed as the protocol unless "http://" is explicitly provided. |
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
|``password`` | String/'' | Password to use to authenticate to Ansible Tower. |
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
|``username`` | String/'' | Username to use to authenticate to Ansible Tower. |
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
|``verify_ssl`` | Boolean/'true' | Whether to force verified SSL connections. |
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
|``verbose`` | Boolean/'false' | Whether to show information about requests being made. |
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
|``description_on``| Boolean/'false' | Whether to show description in human-formatted output. [CLI use only] |
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
|``certificate`` | String/'' | Path to a custom certificate file that will be used throughout the command. Ignored if `--insecure` flag if set in command or `verify_ssl` is set to false |
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
|``use_token`` | Boolean/'false' | Whether to use token-based authentication. |
+------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
**Note:** Some settings are marked as 'CLI use only', this means although users are free to set values to those
settings, those settings only affect CLI but not API usage.
.. autoclass:: tower_cli.conf.Settings
:members: runtime_values
Exceptions
==========
APIs of ``tower_cli`` raise exceptions defined in ``tower_cli.exceptions`` module. Check raise list of resource
public method documentation for possible exceptions.
.. automodule:: tower_cli.exceptions
:members:
import os
import click
from tower_cli import get_resource
from tower_cli.cli import types
from collections import OrderedDict
ATTR_TO_SHOW = [
'name',
'type',
'help_text',
'read_only',
'unique',
'filterable',
'required',
]
CLI_TYPE_MAPPING = {
unicode: 'String',
str: 'String',
types.Related: (lambda x: 'Resource ' + str(getattr(x, 'resource_name', 'unknown'))),
click.Choice: (lambda x: 'Choices: ' + ','.join(getattr(x, 'choices', [])))
}
def convert_type(attr_val):
if attr_val in CLI_TYPE_MAPPING:
return CLI_TYPE_MAPPING[attr_val] \
if isinstance(CLI_TYPE_MAPPING[attr_val], str) \
else CLI_TYPE_MAPPING[attr_val](attr_val)
elif type(attr_val) in CLI_TYPE_MAPPING:
return CLI_TYPE_MAPPING[type(attr_val)] \
if isinstance(CLI_TYPE_MAPPING[type(attr_val)], str) \
else CLI_TYPE_MAPPING[type(attr_val)](attr_val)
try:
return attr_val.__name__
except Exception:
return str(attr_val)
def convert_to_str(field, attr, attr_val):
if attr == 'help_text' and not attr_val:
return 'The %s field.' % field.name
elif attr == 'type':
return convert_type(attr_val)
elif not isinstance(attr_val, basestring):
if attr_val in (True, False, None):
return str(attr_val)
else:
return 'TODO'
return attr_val
def get_content(res_name):
res = get_resource(res_name)
content = OrderedDict()
for field in res.fields:
for attr in ATTR_TO_SHOW:
content.setdefault(attr, [])
attr_val = getattr(field, attr, 'N/A')
attr_val = convert_to_str(field, attr, attr_val)
content[attr].append(attr_val)
return content
def render_table(content):
delimiter = ['+']
titles = ['|']
values = []
for attr_name in content:
column_len = max(len(attr_name), max([len(x) for x in content[attr_name]])) + 1
delimiter.append('-' * column_len + '+')
titles.append(attr_name + ' ' * (column_len - len(attr_name)) + '|')
for i in range(len(content[attr_name])):
val = content[attr_name][i]
if len(values) <= i:
values.append(['|'])
values[i].append(val + ' ' * (column_len - len(val)) + '|')
delimiter = ''.join(delimiter)
titles = ''.join(titles)
values = [''.join(x) for x in values]
table = [delimiter]
table.append(titles)
table.append(delimiter.replace('-', '='))
for val in values:
table.append(val)
table.append(delimiter)
return '\n' + '\n'.join(table) + '\n\n'
def insert_table(rst_path, table):
insert_checkpnt = '.. <table goes here>\n'
with open(rst_path) as f:
file_content = f.read()
start = file_content.find(insert_checkpnt) + len(insert_checkpnt)
end = file_content.rfind(insert_checkpnt)
if start >= 0 and end >= 0:
with open(rst_path, 'w') as f:
f.write(file_content[: start] + table + file_content[end:])
def process_resource(res_name, rst_path):
content = get_content(res_name)
table = render_table(content)
insert_table(rst_path, table)
def main():
for root, dirs, files in os.walk('resources/'):
for file_ in files:
if not file_.endswith('.rst'):
continue
process_resource(file_[: -len('.rst')], os.path.join(root, file_))
if __name__ == '__main__':
main()
API Reference
=============
**NOTE:** This API documentation assumes you are using 3.2.0 and higher versions
of ansible-tower-cli. If you are using a lower version than 3.2.0, there is no
guarantee API usages in this documentation would work as expected.
Introduction
------------
Like Tower UI, Tower CLI is a client talking to multiple REST services of Tower backend, but via Python script
or UNIX command line. Thus the usage of Tower CLI's APIs are pretty straight-forward: get a resource corresponding
to its counterpart in Tower backend, and call public methods of that resource, which in term requests specific REST
endpoint and fetch/render response JSON. Here is a simple example of creating a new organization using Tower CLI in
Python:
.. code-block:: python
from tower_cli import get_resource
from tower_cli.exceptions import Found
from tower_cli.conf import settings
with settings.runtime_values(username='user', password='pass'):
try:
res = get_resource('organization')
new_org = res.create(name='foo', description='bar', fail_on_found=True)
except Found:
print('This organization already exists.')
assert isinstance(new_org, dict)
print(new_org['id'])
The above example shows the pattern for most Tower CLI API use cases, which is composed of 3 parts: runtime
configuration, fetch resource and invoke its public methods, and exception handling.
Tower CLI needs a set of configurations to function properly, all configuration settings are stored in singleton
object ``tower_cli.conf.settings``, which provides a public context manager ``runtime_values`` to temporary override
settings on file with temporary runtime values. see more about Tower CLI configurations in 'Configuration' section.
Most of the resources listed at Tower's endpoint `/api/v2/` have client-side proxy classes in Tower CLI. The two
main ways of getting resource proxies in Tower CLI are:
.. code-block:: python
from tower_cli import get_resource
res = get_resource('<resource name>')
and
.. code-block:: python
import tower_cli.resources.<resource module name>.Resource as <alias>
res = <alias>()
A typical resource in Tower CLI has 2 components: fields and public methods. Resource fields can be seen as wrappers
around actual resource fields exposed by Tower REST API. They are generally used by public methods to create and
modify resources and filter when searching for specific resources; Public methods are the actual wrappers around
querying Tower REST APIs, they can be used both for general CRUD operations against Tower resources, like delete
a user, and for specific tasks like launching an ad hoc command, monitoring a job run or constructing a workflow
graph from script.
In the table of contents below, all available Tower CLI resources are listed, the documentation for each of them all
follow the same structure: a 'Description' section which gives an introduction to the resource; a 'Fields Table'
section which lists all available fields of that resource; and a 'API Specification' section, which expands the usage
detail of every available public method.
Note most public methods have a keyword argument ``**kwargs``. This argument basically contains and only contains
resource fields, unless specified.
Any usage errors or connection exceptions are thrown as subclasses of ``tower_cli.exceptions.TowerCLIError``, see
'Exceptions' section below for details.
Table of Contents
-----------------
.. toctree::
:maxdepth: 1
:caption: Environment Setup
conf.rst
exceptions.rst
.. toctree::
:maxdepth: 1
:caption: Resource List
resources/ad_hoc.rst
resources/credential_type.rst
resources/credential.rst
resources/group.rst
resources/host.rst
resources/instance_group.rst
resources/instance.rst
resources/inventory_script.rst
resources/inventory_source.rst
resources/inventory.rst
resources/job_template.rst
resources/job.rst
resources/label.rst
resources/node.rst
resources/notification_template.rst
resources/organization.rst
resources/project.rst
resources/role.rst
resources/schedule.rst
resources/setting.rst
resources/team.rst
resources/user.rst
resources/workflow_job.rst
resources/workflow.rst
Ad Hoc Commands
===============
Description
-----------
This resource is used for managing and executing ad hoc commands via Tower. While the rest CRUD operations follow
the common usage pattern, an ad hoc command resource cannot be created via the normal way of calling ``create``,
but only be created on-the-fly via ``launch``.
Fields Table
------------
.. <table goes here>
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|name |type |help_text |read_only |unique |filterable |required |
+===================+====================+==============================+==========+=======+===========+=========+
|job_explanation |String |The job_explanation field. |False |False |True |False |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|created |String |The created field. |False |False |True |False |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|status |String |The status field. |False |False |True |False |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|elapsed |String |The elapsed field. |False |False |True |False |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|job_type |Choices: run,check |The job_type field. |False |False |True |True |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|inventory |Resource inventory |The inventory field. |False |False |True |True |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|machine_credential |Resource credential |The machine_credential field. |False |False |True |True |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|cloud_credential |Resource credential |The cloud_credential field. |False |False |True |False |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|module_name |String |The module_name field. |False |False |True |False |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|module_args |String |The module_args field. |False |False |True |False |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|forks |int |The forks field. |False |False |True |False |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|limit |String |The limit field. |False |False |True |False |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
|verbosity |mapped_choice |The verbosity field. |False |False |True |False |
+-------------------+--------------------+------------------------------+----------+-------+-----------+---------+
.. <table goes here>
API Specification
-----------------
.. autoclass:: tower_cli.resources.ad_hoc.Resource
:members: cancel, delete, get, launch, list, monitor, relaunch, status, wait
Credential
==========
Description
-----------
This resource is used for managing credential resources in Tower.
Fields Table
------------
.. <table goes here>
+----------------+-------------------------+---------------------------+----------+-------+-----------+---------+
|name |type |help_text |read_only |unique |filterable |required |
+================+=========================+===========================+==========+=======+===========+=========+
|name |String |The name field. |False |True |True |True |
+----------------+-------------------------+---------------------------+----------+-------+-----------+---------+
|description |String |The description field. |False |False |True |False |
+----------------+-------------------------+---------------------------+----------+-------+-----------+---------+
|user |Resource user |The user field. |False |False |True |False |
+----------------+-------------------------+---------------------------+----------+-------+-----------+---------+
|team |Resource team |The team field. |False |False |True |False |
+----------------+-------------------------+---------------------------+----------+-------+-----------+---------+
|organization |Resource organization |The organization field. |False |False |True |False |
+----------------+-------------------------+---------------------------+----------+-------+-----------+---------+
|credential_type |Resource credential_type |The credential_type field. |False |False |True |True |
+----------------+-------------------------+---------------------------+----------+-------+-----------+---------+
|inputs |structured_input |The inputs field. |False |False |True |False |
+----------------+-------------------------+---------------------------+----------+-------+-----------+---------+
.. <table goes here>
API Specification
-----------------
.. autoclass:: tower_cli.resources.credential.Resource
:members: copy, create, delete, get, modify
Credential Type
===============
Description
-----------
This resource is used for managing credential type resources in Tower.
Fields Table