Upgrade process breaks Zookeeper configuration

[Marco Passalacqua]

Scenario: Upgrade of Contrail Networking Cluster from 3.0.2 to 3.2 via FABRIC in RHOSP8 (Liberty)

After the execution of the upgrade_database task, zookeeper configuration is lost.
During the task execution, YUM upgrades the zookeeper packages creating a new (and clean) /etc/zoo.cfg.

New zookeeper packages change the directory hierarchy for data files:
from /var/lib/zookeeper to /var/lib/zookeeper/data with no moving of the myid file.

Upgrade process seems to don't take in consideration above changes and also it doesn't fix the zoo.cfg file with the previous configurations (in particular cluster information).
Moreover, it should have to move the myid file (on each node) to the new location (/var/lib/zookeeper/data) because the service, after the upgrade, finds this file on the new location.

The result of this issue is that each zookeeper node on the cluster restart in standalone mode and, since no alert is raised, at the end of the upgrade procedure, contrail has wrong behaviours and DBs (Cassandra and Zookeeper) became easily unsycnrhoynized .

[Nagendra Prasath (npchandran)]

Is this still seen after https://bugs.launchpad.net/juniperopenstack/+bug/1677852 ?

[Nagendra Prasath (npchandran)]

fab upgrade scripts needs to updated to handle upstream zookeeper package changes.

[Nagendra Prasath (npchandran)]

Adding "invalid" in Trunk (R4.0) as zookeeper is containerized as a part of contrail controller docker container and no fabric utils will be used.

[Nagendra Prasath (npchandran)]

Could you please provide a system in failed condition...