dbdab8a...
by
OpenDev Sysadmins <email address hidden>
OpenDev Migration Patch
This commit was bulk generated and pushed by the OpenDev sysadmins
as a part of the Git hosting and code review systems migration
detailed in these mailing list posts:
Attempts have been made to correct repository namespaces and
hostnames based on simple pattern matching, but it's possible some
were updated incorrectly or missed entirely. Please reach out to us
via the contact information listed at https://opendev.org/ with any
questions you may have.
This is a mechanically generated change to replace openstack.org
git:// URLs with https:// equivalents.
This is in aid of a planned future move of the git hosting
infrastructure to a self-hosted instance of gitea (https://gitea.io),
which does not support the git wire protocol at this stage.
This update should result in no functional change.
Most production deployments involve 3 nodes for high availability.
This change modifies the default cluster_count to 3 in order to
align with the typical deployment scenario. Previously, the default
cluster count was 2 which is often unmodified and then leads to
deployment failures due to a mismatch in the nodelist defined in
each node's corosync.conf file.
On corosync restart, corosync may take longer than a minute to come
up. The systemd start script times out too soon. Then pacemaker which
is dependent on corosync is immediatly started and fails as corosync
is still in the process of starting.
Subsequently the charm would run crm node list to validate pacemaker.
This would become an infinite loop.
This change adds longer timeout values for systemd scripts and adds
better error handling and communication to the end user.
Failed to delete ocf resources via delete_resources option
Now the charm is using 'crm -w -F resource stop <RES>'
and 'crm -w -F configure delete <RES>' to delete legacy ocf
resource via delete_resources option, but the 'stop' step will
fail when ocf file no longer exists (e.g. due to packages no
longer being available after upgrade). In addition, the daemon
process may still be running after the upgrade in this case.
