is_bootstrap_node fact potential name collisions

[Jiří Stránský]

Many services currently set an `is_bootstrap_node` fact, meaning they
override each other's results when the fact is being set. As long as
the fact doesn't belong into a particular step but it's executed on
every step, nothing bad happens, as the correct is_bootstrap_node
setting directly precedes any service upgrade tasks. However, we
intend to put the fact setting into step 0 in change
Ib04b051e8f4275e06be0cafa81e2111c9cced9b7 and at that point the name
collision would break upgrades (only one service would "win" in
setting the is_bootstrap_node fact).

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/628171

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/628171
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=54fb81ecd94965e6b518060a4760c6aeb3987efe
Submitter: Zuul
Branch: master

commit 54fb81ecd94965e6b518060a4760c6aeb3987efe
Author: Jiri Stransky <email address hidden>
Date: Thu Jan 3 13:50:09 2019 +0100

    Prevent service bootstrap node facts from colliding with each other

    Many services currently set an `is_bootstrap_node` fact, meaning they
    override each other's results when the fact is being set. As long as
    the fact doesn't belong into a particular step but it's executed on
    every step, nothing bad happens, as the correct is_bootstrap_node
    setting directly precedes any service upgrade tasks. However, we
    intend to put the fact setting into step 0 in change
    Ib04b051e8f4275e06be0cafa81e2111c9cced9b7 and at that point the name
    collision would break upgrades (only one service would "win" in
    setting the is_bootstrap_node fact).

    This patch changes the is_bootstrap_node facts in upgrade_tasks to use
    per-service naming.

    Note that fast_forward_upgrade_tasks use their own is_boostrap_node
    logic. We've uncovered some weirdness there while looking into the
    is_boostrap_node issue, but the fix is not a low hanging fruit and
    likely we'll be completely redoing the FFU tasks for Q->T
    upgrade. So the FFU tasks are left alone for now.

    Change-Id: I9c585d3cb282b7e4eb0bacb3cf6909e04a9a495e
    Closes-Bug: #1810408

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/tripleo-heat-templates 10.3.0 release.