@afreiberger As you've already determined, the keystone issue seems to be caused by the keystone-ldap charm which is a reactive charm. aodh is ALSO a reactive charm. This is also happening with designate, which is ALSO a reactive charm.
The common theme is that they are all reactive charms and use the charms.openstack library. What's probably happening in each of the charms is that a reactive handler is triggering the same behaviour over and over again, and that behaviour has the unintended side-effect of triggering a restart. An example of this was in the designate charm, where the common haproxy code in charms.openstack was causing the haproxy.conf file to be re-written every update status, with the same information, but unfortunately in a non-deterministic order (this is almost fixed).
The options are either working through all of the charms and stopping the unintended behaviour (which is tricky, as charms.reactive _wants_ all handlers that have true conditions to run on every hook invocation, and it's hard to 'gate' behaviour to only run once - the states get a bit out of control), or fix layer-openstack so that it includes a custom reactive 'update-status' handler than DOESN'T run the charms.reactive handler system but does allow the introspection of interface (relation) states.
I'll raise a bug in charms.openstack to track this, and reference it back here.
@afreiberger As you've already determined, the keystone issue seems to be caused by the keystone-ldap charm which is a reactive charm. aodh is ALSO a reactive charm. This is also happening with designate, which is ALSO a reactive charm.
The common theme is that they are all reactive charms and use the charms.openstack library. What's probably happening in each of the charms is that a reactive handler is triggering the same behaviour over and over again, and that behaviour has the unintended side-effect of triggering a restart. An example of this was in the designate charm, where the common haproxy code in charms.openstack was causing the haproxy.conf file to be re-written every update status, with the same information, but unfortunately in a non-deterministic order (this is almost fixed).
The options are either working through all of the charms and stopping the unintended behaviour (which is tricky, as charms.reactive _wants_ all handlers that have true conditions to run on every hook invocation, and it's hard to 'gate' behaviour to only run once - the states get a bit out of control), or fix layer-openstack so that it includes a custom reactive 'update-status' handler than DOESN'T run the charms.reactive handler system but does allow the introspection of interface (relation) states.
I'll raise a bug in charms.openstack to track this, and reference it back here.