-
Notifications
You must be signed in to change notification settings - Fork 41
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
🐛 Use postgresql modules for migration #364
Conversation
Signed-off-by: Jason Montleon <jmontleo@redhat.com>
bac1756
to
4b196cd
Compare
Signed-off-by: Jason Montleon <jmontleo@redhat.com>
4b196cd
to
bbb0162
Compare
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
- name: Clean up database dump file | ||
file: | ||
state: absent | ||
path: /tmp/keycloak.sql |
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.
path: /tmp/keycloak.sql | |
path: /tmp/keycloak.sql |
I don't see it used anywhere else besides here ('Dump database', 'Restore database', & 'Clean up database dump file'), so I've no concern leaving it as it is, but did have the thought as I was reviewing, "should this be hard-coded?", and wanted to raise it.
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.
I'm not concerned about it being hardcoded, except that it's predictable if someone was looking for it to try and do something malicious. I think it's easy to generate a name, so I'll probably do that. As an aside I just updated the PR with the change that I think will actually resolve the random lost DB, and added a comment with explanation.
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.
At least I hope it fixes. One success does not make a pattern. Especially since it took all day testing to get a failure. But it at least looks promising.
I left a comment on https://issues.redhat.com/browse/MTA-3335?filter=-1 It looks like the old service was flapping between the new and old DB pod because the selector matched both. You can see that in the verbose output from the source ping task I added. Note between retries the version changed from 15 to 12. This should not be happening. I added a version label for the new deployment and service to prevent it matching the old db pod so the new service was stable, but since nothing was done for the old service it's matching and flipping between both old and new pod. I have updated the name label of the new deployment/pod to incorporate the version in this PR which should prevent the old service from matching and stop the unpredictable results. Old pod deployment labels/service selector:
Updated new deployment labels/service selector:
|
When using psql, errors in applying the sql generated from the dump do not reach bash without adding additional options. psql only generates a non-zero exit code when something fatal happens, like being unable to connect to the database host. So, all ansible sees is exit code 0 from psql and continues on, as if everything is great.
I did some reading up on postgres modules for ansible and we do not need to shell out to do this, so I have implemented it with modules.
Since handling the actual migration with the ansible modules I have not encountered a failure. Continuing to run upgrades to test ...