You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When you upgrade the main Cacti Data Collector, attempting to access the remote Data Collectors will essentially stay in an upgrade loop. This is due to the version table being stuck at the prior version in the version table and not matching the version in the core database.
This is tricky, and is a timing issue since if the replication has not started and succeeded, this replication may cause the tables to be moved ahead of the files. So, maybe instead, as a part of the replicate out, we might want to detect a version change, and perform the full sync automatically for the remote collectors that are online.
To Reproduce
Steps to reproduce the behavior:
Upgrade a main cacti server
Wait for a file sync, which includes the cacti_version file
After file sync is completed, attempt to login to the remote data collector
Note you are stuck in an install loop
Expected behavior
Either upgrade should happen including a full sync, or the upgrade of the main server should include the full sync.
The text was updated successfully, but these errors were encountered:
* After Installing Cacti on Main Data Collector, Full Sync should be performed
* Regression on upgrading a second time for 1.2.8
* Note that there remains an issue where the last two lines are missed from the log until you execute on more refresh of the page.
* This changes also finish i18n of the log_install_always function calls. For some reason, they were not fully i18n and had some issues with the wrong number of parameters in cases.
netniV
changed the title
After Installing Cacti on Main Data Collector, Full Sync should be performed
Main Data Collector should perform a Full Sync whenever it is installed/upgraded
Dec 7, 2019
Describe the bug
When you upgrade the main Cacti Data Collector, attempting to access the remote Data Collectors will essentially stay in an upgrade loop. This is due to the version table being stuck at the prior version in the version table and not matching the version in the core database.
This is tricky, and is a timing issue since if the replication has not started and succeeded, this replication may cause the tables to be moved ahead of the files. So, maybe instead, as a part of the replicate out, we might want to detect a version change, and perform the full sync automatically for the remote collectors that are online.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Either upgrade should happen including a full sync, or the upgrade of the main server should include the full sync.
The text was updated successfully, but these errors were encountered: