-
Notifications
You must be signed in to change notification settings - Fork 584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom Vars not updated after upgrade #6569
Comments
Here are sql dumps of a very minimal config from 2.8.4 and 2.9.1: sqldump.tar.gz While no config has been changed, the hosts have different config checksums, this may have happened because of low level changes to our arrays and maps can change the order of elements. |
If you are having this issue as well, you can help us by providing the following information:
|
This seems unrelated to modified attributes.
|
Possible workaround: Set the config_checksum for Hosts or whatever type is affected to NULL, this will force a complete update of the objects.
Custom vars should now be up to date. |
We're not able to reproduce this, after days of debugging during workhours. The described workaround with truncating the tables (not only the checksum) after upgrade has been updated, and worked for reporters. Therefore we're stopping with further investigation and closing here. |
I found another workaround: For all affected hosts, you have to add an aditional check to the host objects. after a reload the missing customvar section apperars in icinga web2. after this the dummy-check can be removed. |
hi, Question: I cloned a host in Icingaweb2 (which was imported via Puppet) and changed some custom host vars. Now I have "original_attributes" with the original cloned customVars, instead of only the new vars. Now I have the problem, that the apply rules doesn't recognize the changes and execute the checks on that host. I tried both workarounds, without any success:
cu denny |
Please move such questions to https://community.icinga.com :) |
When upgrading from Icinga 2.8.4 to 2.9.X (unconfirmed but suspected for other upgrade paths), users observed Hosts not having their custom var changes written to the DB. See this post
Also:
The text was updated successfully, but these errors were encountered: