Closed bcoca closed 6 years ago
another example:
DOCUMENTATION:
author:
- Jan-Piet Mens (@jpmens)
name: etcd
plugin_type: lookup
version_added: "2.1"
short_description: get info from etcd server
description:
- Retrieves data from an etcd server
options:
_raw:
description:
- the list of keys to lookup on the etcd server
type: list of strings
required: True
_etcd_url:
description:
- Environment variable with the url for the etcd server
default: 'http://127.0.0.1:4001'
env:
- name: ANSIBLE_ETCD_URL
_etcd_version:
description:
- Environment variable with the etcd protocol version
default: 'v1'
env:
- name: ANSIBLE_ETCD_VERSION
EXAMPLES:
- name: "a value from a locally running etcd"
debug: msg={{ lookup('etcd', 'foo') }}
RETURN:
_list:
description:
- list of values associated with input keys
type: strings
In this case etcd takes direct paramters via _raw but indirect configuration via 2 env vars.
I'd change lookup: etcd
to
type: lookup
name: etcd
With the documentation parser having some compat code for the old way (for modules only). ie: fill in type and name from the yaml if they exist. If type is empty, look for "module: foo" and set type = "module". if type is module and name is empty, also set name = "foo".
the plugin_docs PR implemented it this way, we just have to update it to deal with change, though i would avoid 'type' as it is overloaded everywhere, aside from being a python reserved keyword
Just noticed it in the contributor conference. I would like to propose adding one more or couple of more attributes
readonly: This is one of the attribute that is very handy for documentation. This is something that is very common in networking where a server is up or VIP is up etc. You can enable/disable them as configuration but runtime state is read only.
immutable: This is something that can be set only once. There are settings or attributes that cannot be changed. Typically backend will reject those settings but it would be to make it explicit.
Ability to describe nested fields. Eg. like swagger specs do.
I would be willing to contribute if you need volunteers
we already have 'nested' suboptions/subspec .. need to re read what the exact name of key is
@bcoca Would love to get more details on it. The only thing i found was passing mention on http://docs.ansible.com/ansible/devel/dev_guide/developing_modules_documenting.html
its been added in 2.4, no good docs on it yet
done on user side, pushed out with 2.4, many plugin types documented using this format.
Proposal: expand documentation fields
Author: Brian Coca <@bcoca>
Date: 2017/03/-1
Motivation
Provide more information while requiring authors to type less
Problems
Types are unclear in some cases, in others we have authors repeat a lot of 'formulaic' documentation. Many plugins rely on configuration and we don't have a good way to expose that to user currently.
Solution proposal
Add 'type' field to current docs, could be one of suported types
'bool', 'list', 'dict', 'integer', 'str'
, etc. This would allow us to use a generic language describing types and in the case of booleans provide the 'choices' section vs having authors copy and paste it 100s of times.Add config/env_vars/hostvars sub sections, for 'options' that allows specifying config/env var settings that affect the plugin
new Deprecated field that has both version and description, version denotes when it will be removed, despcription should contain why and alternatives.
short example of ssh connection plugin:
Dependencies (optional)
Not really a dependencies but related PRs:
Documentation (optional)
Requires writing plugin docs ...
Additional