Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #2520] statusmap: multiple parents not possible, only last one drawn #747

Closed
icinga-migration opened this issue Apr 13, 2012 · 19 comments
Closed

[dev.icinga.com #2520] statusmap: multiple parents not possible, only last one drawn #747

icinga-migration opened this issue Apr 13, 2012 · 19 comments
Labels
enhancement Interface Features

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/2520

Created by bjwahl on 2012-04-13 12:20:00 +00:00

Assignee: (none)
Status: Closed (closed on 2014-07-19 13:58:30 +00:00)
Target Version: (none)
Last Update: 2014-07-19 13:58:30 +00:00 (in Redmine)

Nach Update von der Version 1.4.0 auf 1.6.1 werden in der Statusmap wenn beim Host mehrere Parents eingetragen sind nur jeweils der letzte Eintrag genommen.

Ändere ich z.B. die Reihenfolge zieht wieder der letzte aber kein anderer.

define host {
use tpl_windows
host_name xxxxxxxx
alias xxxxxxxx
address xxxxxxxx
notes_url https://xxxxxxxxHOSTNAME$
parents hosta,hostb,hostc,hostd,hoste
hostgroups +,rdp
register 1
}

Die cfg ist unter 1.4 und 1.6.1 die gleiche. Update auf 1.6.2 hat auch zu keinen Erfolg geführt.

Attachments

Relations:
@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-13 12:31:02 +00:00

  • Subject changed from status.cgi Parents werden nicht mehr alle verbunden, sondern nur der letzte Eintrag to statusmap.cgi Parents werden nicht mehr alle verbunden, sondern nur der letzte Eintrag

english please.

is this an icinga-web or classic ui issue (already asked that on the portal)?
http://www.monitoring-portal.org/wbb/index.php?page=Thread&postID=169173#post169173

@icinga-migration
Copy link
Author

Updated by bjwahl on 2012-04-13 12:47:36 +00:00

Ok, english should be possible.

It is the icinga-web interface. Classic and status.cgi is not installed.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-17 07:20:32 +00:00

  • Subject changed from statusmap.cgi Parents werden nicht mehr alle verbunden, sondern nur der letzte Eintrag to statusmap: Parents werden nicht mehr alle verbunden, sondern nur der letzte Eintrag

@icinga-migration
Copy link
Author

Updated by mhein on 2012-04-18 09:16:18 +00:00

  • Assigned to set to jmosshammer

@icinga-migration
Copy link
Author

Updated by QIONIS on 2012-07-26 10:23:31 +00:00

Hello,

I have the same problem... Only the last parent in "parents" is selected.
How I do to see the two parents linked with one "child" ?

Thanks

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-07-26 11:17:18 +00:00

  • Category set to Interface Features
  • Assigned to changed from jmosshammer to mhein
  • Target Version set to 1.8

see http://www.monitoring-portal.org/wbb/index.php?page=Thread&postID=175051#post175051 as well as a possible fix in #2816

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-09-23 11:21:32 +00:00

  • (unknown custom field) set to 1
  • (unknown custom field) set to 1
  • (unknown custom field) set to 1
  • (unknown custom field) set to Debian 6.0.5
  • (unknown custom field) set to MySQL
  • (unknown custom field) set to 5
  • (unknown custom field) set to chromium 21

can you check back with the current git master please? there have been plenty of fixes applied for statusmap now.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-10-04 14:12:41 +00:00

  • File added 2520.cfg
  • File added icinga_classic_1.8_statusmap_multiple_parents.png
  • File added icinga_web_1.8_statusmap_multiple_parents.png
  • Subject changed from statusmap: Parents werden nicht mehr alle verbunden, sondern nur der letzte Eintrag to statusmap: multiple parents not possible, only last one drawn

finally, i understood the topic, which is pretty much misleading. so icinga web does not draw all parents, but only the last one, while icinga classic ui.

attached is a config file (also on core git) to reflect that.

classic ui
icinga_classic_1.8_statusmap_multiple_parents.png

web
icinga_web_1.8_statusmap_multiple_parents.png

@icinga-migration
Copy link
Author

Updated by QIONIS on 2012-10-04 14:26:05 +00:00

Thanks for follow the topic..

So, for the moment isn't exist solution for my problem..?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-10-05 10:42:50 +00:00

  • Status changed from New to Assigned

i've only debugged it, though i am not sure where the logic on the drawing happens, or likewise, what did change.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-10-05 13:53:36 +00:00

ok, short guess - with 1.5 the newly written doctrine api was introduced, so probably the queries changed on that backend, returning faulty information overall.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-10-06 10:48:17 +00:00

there was a recent change of attaching the reference of the child to the array.

        // connect childs to parents
        foreach($hostWithParents as $objectId=>$parentId) {
            if(isset($hosts[$parentId]))
               $hosts[$parentId]["children"][] = &$hosts[$objectId];
            else // if parent node is missing, connect to top level
                $hosts[$objectId]["parent"] = -1;
        }

though, i don't think that this is entirely incorrect, rather the functionality of how to fetch multiple parents is possibly wrong.

going into the backend, the parenthosts will be determined by this table.

mysql> select * from icinga_host_parenthosts;

within app/modules/Cronks/models/System/StatusMapModel.class.php there the selection of the HOST_PARENT_OBJECT_ID which is a single id (or row). my guess is that the underlaying doctrine api could possibly return multiple rows on that exact host.

even more, the loop will possible have multiple hosts with different parents matched being put into the $hostWithParents[$objectId] array.

        foreach($apiResHosts as $row) {

            if ($row['HOST_IS_PENDING'] == '1') {
                $row['HOST_CURRENT_STATE'] = "99";
            }

            $objectId = $idPrefix . $row['HOST_OBJECT_ID'];

            $hosts[$objectId] = array(
                'id'        => $objectId,
                'name'      => $row['HOST_NAME'],
                'data'      => array("relation"=>$row),
                'children'  => array(),
                'parent' => $row['HOST_PARENT_OBJECT_ID']
            );
            if($row['HOST_PARENT_OBJECT_ID'] != -1) {
                $hostWithParents[$objectId] = $idPrefix.$row['HOST_PARENT_OBJECT_ID'];
            }
        }

so, $hostWithParents[$objectId] is being processed again within a loop below. question remains - are there multiple hosts with parents already in the array, or does the children array get populated wrong?

        // connect childs to parents
        foreach($hostWithParents as $objectId=>$parentId) {
            if(isset($hosts[$parentId]))
               $hosts[$parentId]["children"][] = &$hosts[$objectId];
            else // if parent node is missing, connect to top level
                $hosts[$objectId]["parent"] = -1;
        }

conclusion - web devs should have a look.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-10-06 11:12:38 +00:00

ok, there can't be multiple hosts in $hostWithParents[$objectId] array, as $objectId (HOST_OBJECT_ID) is a unique identifier to the host.

though, a host can have multiple parents, which is totally leftout here

'parent' => $row['HOST_PARENT_OBJECT_ID']

even if this is a combined query, with all relations fetched, only the last HOST_PARENT_OBJECT_ID wins due to the fact that $objectId is unique, and the rest will be overridden.

proposal

  • change 'parent' to an array, getting all possible host parents on a per host_object_id query
  • add the parents array to the processing of how to determine multiple children for the host
  • this will require some nested loops

sort of

$hostWithParents[$objectId][] = $host_obj_id_arr;

which then gets questioned of not only a single parent, but multiple, and reversed - more childs.

@icinga-migration
Copy link
Author

Updated by jmosshammer on 2012-10-06 11:26:50 +00:00

This would require a rewrite of the structure, instead of a parent~~child construction we need to use a node~~>adjacencies structure, see http://thejit.org/static/v20/Jit/Examples/RGraph/example2.html

This is a bug for a long time, but I don't know if we want to change this in 1.8, as changing the data format of the statusmap provider is a bigger change

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-10-06 12:10:01 +00:00

  • Assigned to changed from mhein to jmosshammer

Ok, thanks for the explaination. I kind of feared that the dataset would require more changes on that.

Let's stick with - first resolve the other open issues of the 1.8 roadmap, and then provide final feedback here. My guess is, that 1.9 should give us more time on that.

@icinga-migration
Copy link
Author

Updated by jmosshammer on 2012-10-09 14:38:47 +00:00

  • Target Version changed from 1.8 to 1.9

1.9, there were major changes in the statusmap, so I think it's too risky to change the data structure a week before the release

@icinga-migration
Copy link
Author

Updated by mfrosch on 2013-03-11 12:12:43 +00:00

  • Tracker changed from Bug to Feature
  • Target Version changed from 1.9 to 1.10

This is considered a feature, which would require a patch to the jit component.

Delayed for a future release.

@icinga-migration
Copy link
Author

Updated by mfrosch on 2013-09-10 15:27:33 +00:00

  • Status changed from Assigned to Feedback
  • Assigned to deleted jmosshammer
  • Target Version deleted 1.10

I'm afraid we can't provide such a feature as of now. Jit graphs doesn't support this linking.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-07-19 13:58:30 +00:00

  • Status changed from Feedback to Closed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement Interface Features
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@icinga-migration