Some raw ideas from a Jet neophyte...
In writing my first Jet roles, I find myself wanting constructs like
get_url(url: <>, dest: <>)
, make_symlink(src: <>, tgt: <>)
,
expand_tarfile(path: <>, dest: <>)
.
With the V1 system, I can get the job done with the copy
and shell
modules.
In V2 we will have script
and external_module
. So there are no barriers
to move forward now, and things will get even better with V2.
And yet - this style of writing is verbose and tedious. It relies heavily on scripts and external modules.
Could there be a way to operate with more focus on Jet primatives, and fewer scripts and 3rd party modules?
Current role.yml syntax:
name: an optional comment
defaults:
var1: value1
var2: value2
tasks:
- task1.yml
- task2.yml
Current playbook.yml syntax:
- name: roles demo
groups: ["all"]
roles:
- role: common
- { role: example_app_two, vars: { port: 3005, sword: 1, battlecat: 1 } }
tasks:
- task1.yml
- task2.yml
Possible alternative role.yml syntax:
name: an optional comment
defaults:
var1: value1
var2: value2
actions:
- {role: get_url.yml, vars: {url: http://bingo.com, dest: /tmp/bingo.txt}}
- task: task1.yml
- task: task2.yml
Possible alternative playbook.yml syntax:
- name: roles demo
groups: ["all"]
actions:
- role: common
- { role: example_app, vars: { port: 3005, sword: 1, battlecat: 1 } }
- task: task1.yml
- task: task2.yml
The core syntax change would be to substitute roles
and tasks
for actions
.
The core architectural change is that roles would become hierarchical. In this way, roles could encapsulate functionality and be composable.
I think it would be helpful for the Jet team to have a dynamic where the core devs can focus on a small set of very high quality built-in modules that would be easy for end-users to compose in the field.
Possible upsides:
- reduce the need for external scripts and modules (easier code reviews & auditability?)
- reduce the pressure on the core team to create a huge variety of built-in modules (IMO a core weakness of Ansible)
- identical
action
syntax in playbooks and roles (reduced cognative overhead)
Possible downsides:
- need to check for loops!
- more complexity! (maybe?)
Michael has said he wants to avoid "YAML Programming". But Jet already has Control Flow elements and Hierarchical Groups. Maybe Hierarchical Roles wouldn't be such a huge leap.
I don't have the experience to judge if a change like this would be beneficial in the long term, but hope that experienced hands would find these ideas interesting. ;-)