Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change request: make ara fail-safe for playbooks #124

Open
dbazhal opened this issue Aug 3, 2017 · 3 comments
Open

Change request: make ara fail-safe for playbooks #124

dbazhal opened this issue Aug 3, 2017 · 3 comments

Comments

@dbazhal
Copy link

dbazhal commented Aug 3, 2017

Hi there.
Here are my thoughts. There should be config option to let ara fail silently - if it fails to do or log something, it should not break the playbook it is used in. Option would be usable in production-critical playbooks - ara problems(like insufficient disk space at ara db) should not stop my playbooks main functionality - configure production systems.

@sca-
Copy link

sca- commented Aug 3, 2017

+1
must-have

@dmsimard
Copy link
Owner

dmsimard commented Aug 3, 2017

Hi, thanks for the feedback.

I feel like this would be a shared responsability between Ansible itself and ARA.
Ansible shouldn't let a callback that is misbehaving interrupt a running playbook.

As far as I am aware, this is currently the case -- throughout the development of ARA, there has been multiple times where ARA was erroring out with a stack trace and it didn't prevent Ansible from running.
You can see an example of this here: http://logs.openstack.org/37/481837/13/check/gate-ara-integration-py35-latest-ubuntu-xenial-nv/5f02d97/console.html.gz#_2017-07-20_01_00_09_924097

In case of timeouts, or latency related issues, it's a bit more nuanced.
I think Ansible will not give up until the callback has returned something. That's worth exploring.

In the context of ARA, we're not enforcing any kind of timeouts right now so I guess we are essentially using defaults provided by sqlalchemy, whatever they are. Putting timeouts too low is something we have to be wary of, but we could surely do a better job at exception handling.

@dmsimard
Copy link
Owner

dmsimard commented Aug 3, 2017

I've created an issue for this upstream: ansible/ansible#27705

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants