Thanks for your reply. It will be easy to see if it works as expected.
I have a test environment where I can reproduce the behavior, so I’m
excited to try it out. :-)
Zitat von Chris Lumens <clum...@redhat.com>:
These are OpenStack control nodes, and their mysql is managed by
galera for high availability. So the standalone mysql service will
never be active here. I verified for several services (like
nova-api, nova-conductor etc.) that simply removing mysql from the
"Wants" statement fixed the issue for me.
During research I stumbled upon this
report (https://bugs.clusterlabs.org/show_bug.cgi?id=5404) which also
mentioned the approach to talk to systemd via dbus.
Yeah, this is the upstream issue that should be fixed by the improvement
I mentioned.
Is it reasonable to assume that the new pacemaker version will fix
what I described above? For now I'm thinking about using a drop-in
file to remove mysql from the "Wants" statement for all affected
units.
Hm, without testing, I'm not really sure. This isn't something we tried
when working on the new dbus integration.
However, my guess from looking at the code is that we should now be
handling this properly. Pacemaker will wait for systemd to give it a
signal telling it that starting the unit finished, along with the
result.
The Wants will fail, but that shouldn't be fatal. They'll either fail
quickly, or it'll take them a while to time out. But, that shouldn't
matter as far as pacemaker is concerned. We'll wait to hear back from
systemd instead of giving up due to some internal timeout.
- Chris
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
