terra-nova
commented
2 years ago Just to expand a bit on the issue, because neither the proposed workarounds (see issues #2554, #2487) nor the recent commits to master (e.g. https://github.com/Icinga/icingaweb2-module-director/commit/9a0279b111803a362c00f342bacfde775eb865f6) seem to help with this.
We have defined a new Service Set with a single service using the Director Web UI.
Clicking on a service in the "Services" tab of the service set definition, we get the aforementioned error meesage:
Uncaught Error: Call to a smember function toString() on null in /usr/share/icingaweb2/modules/director/application/controllers/ServiceController.php:255
Stack trace:
#0 /usr/share/icingaweb2/modules/director/library/Director/Web/Controller/ObjectController.php(497): Icinga\Module\Director\Controllers\ServiceController->loadObject()
#1 /usr/share/icingaweb2/modules/director/library/Director/Web/Controller/ObjectController.php(90): Icinga\Module\Director\Web\Controller\ObjectController->loadOptionalObject()
#2 /usr/share/icingaweb2/modules/director/application/controllers/ServiceController.php(46): Icinga\Module\Director\Web\Controller\ObjectController->init()
#3 /usr/share/php/Icinga/Web/Controller/ActionController.php(170): Icinga\Module\Director\Controllers\ServiceController->init()
#4 /usr/share/php/Icinga/Web/Controller/Dispatcher.php(59): Icinga\Web\Controller\ActionController->__construct(Object(Icinga\Web\Request), Object(Icinga\Web\Response), Array)
#5 /usr/share/icingaweb2/library/vendor/Zend/Controll
#0 [internal function]: Icinga\Application\Web->Icinga\Application\{closure}()
#1 {main}The code in /usr/share/icingaweb2/modules/director/application/controllers/ServiceController.php:255 runs the following query against our PostgreSQL database:
SELECT icinga_service.uuid FROM icinga_service WHERE (object_name = 'Filesystem /var/lib') AND (service_set_id = '1875')This query returns no results. There is a row in icinga_service with object_name = 'Filesystem /var/lib', but the service_set_id colums is 1871, not 1875:
# select * from icinga_service where (object_name = 'Filesystem /var/lib');
-[ RECORD 1 ]-----------+-----------------------------------
id | 8517
object_name | Filesystem /var/lib
object_type | object
disabled | n
...
service_set_id | 1871
template_choice_id |
check_timeout |
flapping_threshold_high |
flapping_threshold_low |
uuid | \xec589041f7874bff90f603176d965f35service_set_id 1871 refers to the service set record with object_type "template", while service_set_id 1875 refers to the service set record with object_type "object" (because the service set has been manually assigned to a host):
# select * from icinga_service_set where id in (1871, 1875);
id | host_id | object_name | object_type | description | assign_filter | uuid
------+---------+-------------------------------------+-------------+-------------+---------------+------------------------------------
1871 | | OS/Linux/SSH/Kubernetes Master Base | template | | | \xb631467cd86b411dae5a88f2e80690b2
1875 | 5774 | OS/Linux/SSH/Kubernetes Master Base | object | | | \xe90a07059b8d4a1ca519a317e555ec7c
(2 rows)It seems to me that, since we are trying to manipulate a service in the service set template itself, we are really looking for the service set with id 1871, not 1875. In effect, the database records seem valid, but the lookup code does not?
Thomas-Gelf
Wintermute2k6
SylvainMartin-LMSYS
Expected Behavior
It should be possible to manipulate services in a serviceset using the Director GUI (or the underlying REST API calls).
Current Behavior
When trying to modify services in a service set, we get the following error messages for some (but not all) services:
Possible Solution
We are aware of the workarounds offered in #2554, #2487 etc., but none of those worked for us. Checking out director master branch did not help either.
The one difference I can think of is that our Director database lives in PostgreSQL, not MySQL. We were not able to reproduce the issue on another installation using MySQL, however that environment has only a fraction of the service sets we have on the main (PostgreSQL-backed) instance.
Steps to Reproduce (for bugs)
Your Environment
icinga2 --version): 2.13.5