(POC) (8) Linchpin Hooks: Pinfile should provide a 'post_actions' yaml list

[centos-paas-sig]

(POC) (8) Linchpin Hooks: Pinfile should provide a 'post_actions' yaml list

[herlo]

Further conversation between myself and @samvarankashyap revealed a semi-solid yaml format in the PinFile which will use hooks. There will be four basic types of hooks:

• pre-provision (likely called `pre-up')
• pre-teardown (likely called `pre-down')
• post-teardown (likely called `post-down')
• post-provision (likely called `post-up')

The last will allow additional state functionality. The concept being that if an inventory is being generated, a hook may wish to take output data, and massage it before allowing inventory generation to happen. It's possible other hooks will allow for additonal states in the future as well.

Below is an example PinFile, which conveys the use of the hooks. Below that, is a possible directory tree of this feature.

 # global hooks to be used by name
hooks:
  post-up:
    - name: check_ssh
      type: ansible
        targets:
          - check_ssh.yml

# PinFile target for openstack
openstack:
  topology: openstack_server.yml
  layout: openshift-cluster.yml
  hooks:
    post-up:
      name: do_something
        type: golang
        action_manager: golang_manager
        actions:
          - do_this.go
      name: manipulate_inventory
        state: before_invgen
        type: ansible
        path: my_ansible_stuff
        actions:
          - add_many_global_vars_so_i_dont_have_to_create_it_in_a_layout.yml
            vars_file: amgvsidhtciial.yml
      name: check_ssh
      name: build_openshift_cluster
        type: ansible
        actions:
          - setup.yml
          - origin_from_source.yml
          - openshift_ansible_from_source.yml
          - deploy_aosi.yml
          - run_e2e_tests.yml
    pre-down:
      name: teardown_jenkins
      type: python
      actions:
          - TOPO="{{ topology }}" /usr/bin/python2.7 paws group -n my_test.yml

Within a PinfFile, hooks can be either global or local to a target. Global ones are declared with the hooks heading and can be used in any target. Additionally, built-in hooks will likely exist.

Interpolation of the topology, layout, output, inventory, and other variables will be available to specific hooks. Determinations about when data is available should be clear (eg. outputs are not generated until after provisioning completes).

Actions are performed based upon their provided type. If no type is listed, a shell action will be default. Actions do not generally cause linchpin to exit. Rather, the error message is displayed, and processing moves forward. However, exit-on-error: True can be passed to a specific action. If said action indeed errors, linchpin will exit with an appropriate error code. If exit-on-error: False (default) is set, linchpin will continue on as if no error happened. Assuming linchpin exits properly, the error code will be 0 (success) in that case.

Built-in actions are of three types:

• shell (default)
• Ansible
• python

Action Managers can be created and loaded via a proxy class (ironically called ActionManager) to allow processing of actions beyond the built-in types. The example yaml above shows an action_manager named golang_manager. This could allow for scripts written in go to be imported and executed natively.

Below is an example linchpin layout, including already existing files and paths, plus new ones to accommodate the hooks functionality being described in this issue.

lp_workspace/
├── hooks
│   ├── ansible
│   │   ├── build_openshift_cluster
│   │   │   ├── deploy_aosi.yml
│   │   │   ├── openshift_ansible_from_source.yml
│   │   │   ├── origin_from_source.yml
│   │   │   ├── run_e2e_tests.yml
│   │   │   └── setup.yml
│   │   ├── _global
│   │   │   ├── check_ssh.yml
│   │   │   └── vars
│   │   └── managers
│   ├── golang
│   │   └── managers
│   │       └── golang_manager.go
│   ├── my_ansible_stuff
│   │   ├── manipulate_inventory
│   │   │   └── add_many_global_vars_so_i_dont_have_to_create_it_in_a_layout.yml
│   │   └── vars
│   │       └── amgvsidhtciial.yml
│   └── python
│       └── teardown_jenkins
│           └── teardown_jenkins_slave.py
├── inventories
├── layout
├── outputs
├── PinFile
└── topology

This is a ROUGH DRAFT of the concept, and needs continued care and feeding to improve the design. If you have thoughts or additional suggestions, please feel free to comment here, or join us on #linchpin on the Freenode IRC network.

[ralphbean]

/cc @mprahl @danalanerh - any idea if this would handle our sleep / wait_for problems?

[mprahl]

@ralphbean I think this could work, but it's only a marginal improvement over running the playbook separately in Jenkins.

[danalanerh]

FYI. The post_actions section for linchpin is not currently there. It's a placeholder and probably not going to be available until the 1.0 release.

…

On Fri, Feb 24, 2017 at 9:17 PM, Matt Prahl ***@***.***> wrote: @ralphbean <https://github.com/ralphbean> I think this could work, but it's only a marginal improvement over running the playbook separately in Jenkins. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#96 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXTgp6UvKfeqgj7v7NqM5-OyQIFrtCQRks5rf488gaJpZM4Krz9H> .

-- Dana Lane Principal Quality Engineer Red Hat, Westford, MA

[herlo]

Hooks