python-tripleoclient exits with status code 0 when overcloud deploy fails

[Sagi (Sergey) Shnaidman]

Python-tripleoclient exits with code 0 when overcloud deploy fails.
It's better to use error status code in these cases.

[Alex Schultz (alex-schultz)]

Raising to high because this makes it very hard for automation to work right

[Ben Nemec (bnemec)]

This is definitely not always the case, for example: http://logs.openstack.org/60/448460/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-nonha/c877061/console.html#_2017-03-22_18_54_15_747619

Do you have a link to a job where it failed and returned 0?

[Alex Schultz (alex-schultz)]

I think this spawned from Bug 1674955

[Sagi (Sergey) Shnaidman (sshnaidm)]

Right, you can see an example in that bug:
http://logs.openstack.org/79/445479/3/check/gate-tripleo-ci-centos-7-nonha-multinode-oooq/2da08a1/logs/undercloud/home/jenkins/overcloud_deploy.log.txt.gz#_2017-03-22_09_38_06

It's actually difficult to find the case where it exits with non-zero.

[Adriano Petrich (apetrich)]

It looks like related or duplicate of https://bugs.launchpad.net/tripleo/+bug/1675709

[Michele Baldessari (michele)]

Adriano I am not 100% sure they are duplicate, although they *might* be somehow related.

I mean in this bug here we see that the deployment failed http://logs.openstack.org/79/445479/3/check/gate-tripleo-ci-centos-7-nonha-multinode-oooq/2da08a1/logs/undercloud/home/jenkins/overcloud_deploy.log.txt.gz#_2017-03-22_09_38_06 but oooq got a return code == 0.

bug 1675709 actually shows that the deployment succeeded and it seems the output of the deploy command is confirming that with all the steps turning to COMPLETE, but we have an issue in the generation of the overcloudrc.

It might turn out that both problems have the same root cause, but until then I would think it is best to keep them separate.

[Adriano Petrich (apetrich)]

The source for this problem is still eluding us.

Some experiments show that some RuntimeErrors might be silently catching somewhere and not propagating but we are not able to reproduce it consistently. We are moving our exceptions that are subclassed as RuntimeErrors into pure Exceptions. Although we are not 100% sure it will solve the problem.