Idea for Composable Jet Actions

composable_jet_actions.md

Composable Jet Actions

Some raw ideas from a Jet neophyte...

Background

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?

Idea for Modified Jet Syntax:

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.

Pros and Cons

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. ;-)