(2) linchpin CLI command does not exit non-zero when an Ansible play fails about linchpin

[robled]

I haven't done enough development on linch-pin to be authoritative on the best way to implement this, but what @herlo just suggested sounds like it will work just fine for my use case.

[samvarankashyap]

@robled : Good catch . Linchpin cli as of now just initiates the Ansible API and does not return anything. I guess we can return Ansible API exit status through linchpin.

[herlo]

@robled can you look at this with regard to the latest develop tree?

[robled]

Just tested using the latest code from develop as of the time of this post, but I still get exit code zero if I simulate a provisioning failure:

(linchpindevelop) [vagrant@localhost openstack-slave]$ git -C ~/linch-pin/ branch
* develop
(linchpindevelop) [vagrant@localhost openstack-slave]$ linchpin --version
linchpin version 1.0.0a4
(linchpindevelop) [vagrant@localhost openstack-slave]$ linchpin rise
target: cinch, action: up

PLAY [schema check and Pre Provisioning Activities on topology_file] ***********

<snip>

TASK [openstack : Including credentials of current resource cinch-group] *******
fatal: [localhost]: FAILED! => {"ansible_facts": {}, "changed": false, "failed": true, "message": "Unable to find 'roles/openstack/vars/os_creds.yml' in expected paths."}
        to retry, use: --limit @/home/vagrant/linch-pin/linchpin/provision/site.retry

PLAY RECAP *********************************************************************
localhost                  : ok=13   changed=0    unreachable=0    failed=1

(linchpindevelop) [vagrant@localhost openstack-slave]$ echo $?
0

[herlo]

After pondering this some, it's clear this is not a simple thing to resolve. In fact, there are many things to consider. For instance, what if the provisioning works for one of the topologies, but not the other. Is that still a failure? And if so, what error code do we assign? It also brings up the question of whether or not things should continue running on a failure of one particular action. Some of these can be managed by flags or options for sure, but a return code is a pretty vague representation of what actually happened.

Currently, I'm thinking that linchpin needs to manage error handling differently at the api level than from the cli level. We can definitely fail (exit 1, sort of thing) in the runcli functionality. If this is all you need, that can be adapted easily enough. If the playbooks fail, or the cli fails, exit 1. Additionally, we're going to be putting together a RESTful api at some point in the future (probably around 1.2), which will handle errors differently as well.

What I want to understand, from the perspective of this issue, is if exit 1 is good enough for you when ANYTHING fails?

[herlo]

Per discussions with @robled and @samvarankashyap and others, we decided to approach this piecemeal. For the command line interface, a return code will be given if any failure happens along the way. Essentially, each command-line function will be wrapped in a try/except clause. When an exception is raised, the cli tooling will return error codes that match the ones here: https://github.com/ansible/ansible/blob/devel/bin/ansible#L115