-
Notifications
You must be signed in to change notification settings - Fork 898
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
Only run the setup playbook the first time we start embedded ansible #15225
Only run the setup playbook the first time we start embedded ansible #15225
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but looks like the call sequence change broke the ansible runner spec.
@miq-bot add_label blocker |
698869e
to
d477f2c
Compare
It needs to run once to put files in place and such, but it restarts services in a way that could cause us to operate on a running stack only to have it restart from under us. This change makes us only run the setup playbook once so the chance of hitting this kind of issue should be much smaller. This effectively combines the .configure and .start methods so that we detect when we are in the first configuration state vs just starting up the services. https://bugzilla.redhat.com/show_bug.cgi?id=1455063
d477f2c
to
0ec1271
Compare
Checked commits carbonin/manageiq@060a0c4~...0ec1271 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
Only run the setup playbook the first time we start embedded ansible (cherry picked from commit 1fa4663) https://bugzilla.redhat.com/show_bug.cgi?id=1455618
Fine backport details:
|
It needs to run once to put files in place and such, but it restarts services in a way that could cause us to operate on a running stack only to have it restart from under us.
This change makes us only run the setup playbook once so the chance of hitting this kind of issue should be much smaller.
This effectively combines the
.configure
and.start
methods so that we detect when we are in the first configuration state vs just starting up the services.https://bugzilla.redhat.com/show_bug.cgi?id=1455063
/cc @ghjm @matburt