Import virtual chassis

[kuhball]

I'm trying to import virtual chassis from netbox into icinga. Since there already is a virtual_chassis_keyid field on the import source this seemed possible.

Goal
Have one host with the virtual chassis name per chassis. This host should contain all interfaces from the whole chassis.

Issue
The netbox API performs different from the UI. The UI is displaying all interfaces on the master of the virtual chassis. The API however returns only the interfaces of the master device. This seems to be by design as there is an extra filter for virtual chassis on interfaces.

Is this solvable with the current implementation? I believe it's necessary to add a new type 'virtualchassis' in the import source. Happy to provide a PR if this solution seems feasible.

[sol1-matt]

Hi @kuhball ,

I've not used Virtual Chassis myself so I'll take your word on how it should be used in Netbox.

The goal of any _keyid is to be able to link objects in Icinga that are linked in Netbox easily. The reason to do this is so you can independently create a template sync rule and safely import it into your host in another sync rule.

Based on what you are describing above, I'd say you'll get the result you want by implementing this.

Happy for you to provide a PR for this. You'll need a constant for the Virtual Chassis, use 28, and I try to keep the order of form->addElement, the switch ($mode) and function calls to get the objects in Netbox.php inline with the constants ordering.

Please also test not only the code but that your config is viable afterwards, on a couple of occasions I've tried to use objects and added them to the import module only to find that it didn't result in viable config in Icinga or I need to change the code so it retrieves the data differently to get viable Icinga config.

[kuhball]

Hej @sol1-matt ,

while implementing I came across an issue and would like your feedback on this.

Implementing Virtual-Chassis as a new object type has some disadvantages to it. Most of the needed parameters are not available on the virtual-chassis but only on the master chassis member.

My current approach was:

• Iterate over all virtual-chassis
• fetch interfaces for the whole chassis

But as you already mentioned this doesn't work configuration wise in icinga since f.e. the primary_ip is missing.

Another approach could be to check if a device is member of a virtual_chassis and if it's the master. If this is the case the interfaces of all members get imported for the master member. All other devices are handled as before. This would reflect the ui in netbox.

I don't know if this breaks the plugin in a certain way for people. Does it make sense to have a separate toggle to enable this functionality?

[sol1-matt]

Changes must not change existing Icinga config in any way, all changes must be backwards compatible

Ignoring new code for a sec, can you give me an example of the api objects you have (sanatized) and then what Icinga host objects you'd like to end up with based on that data.

[kuhball]

Here is a virtual_chassis api object, grabbed from the demo netbox:

{
            "id": 1,
            "url": "https://demo.netbox.dev/api/dcim/virtual-chassis/1/",
            "display_url": "https://demo.netbox.dev/dcim/virtual-chassis/1/",
            "display": "r105-torsw",
            "name": "r105-torsw",
            "domain": "",
            "master": {
                "id": 98,
                "url": "https://demo.netbox.dev/api/dcim/devices/98/",
                "display_url": "https://demo.netbox.dev/dcim/devices/98/",
                "display": "r105-torsw:1",
                "name": null
            },
            "description": "",
            "owner": null,
            "comments": "",
            "tags": [],
            "custom_fields": {},
            "created": "2021-12-30T00:00:00Z",
            "last_updated": "2021-12-30T16:17:05.090000Z",
            "member_count": 2,
            "members": [
                {
                    "id": 98,
                    "url": "https://demo.netbox.dev/api/dcim/devices/98/",
                    "display_url": "https://demo.netbox.dev/dcim/devices/98/",
                    "display": "r105-torsw:1",
                    "name": null
                },
                {
                    "id": 99,
                    "url": "https://demo.netbox.dev/api/dcim/devices/99/",
                    "display_url": "https://demo.netbox.dev/dcim/devices/99/",
                    "display": "r105-torsw:2",
                    "name": null
                }
            ]
        },

The goal is to have a host in icinga with interfaces from the whole chassis. But chassis cannot have contacts f.e. these still have to be assigned to devices.

Initially in my first approach I used the Device import Source with status=active&cf_icinga_monitoring=True&virtual_chassis_member=True&vc_position=1 as search filter. And then did a property modifier and used virtual_chassis_keyid as keyid. This was perfect since all the data came from the first chassis member. Only downside - I'm missing all the interfaces from the other members.

[sol1-matt]

Thanks @kuhball , this gives me a clearer picture of what you are attempting.

Without changing any code I'd see if directors sync rules can handle this if you use update policy: merge. I'm not sure if that will work but it is my first thought.

The second thought would be to use virtual chassis objects as the source for the host and device objects as the source for the host templates then try and glue them all together but I don't think that will work or if it does I'm not sure how "nice" it will be.

If I was looking to implement this in code, I'd probably start with adding virtual chassis to the import, then using the existing "Link Interfaces" checkbox to get it to read all the interfaces from member. So the UI isn't more complicted (but we'd want the readme to be clear). You might be able to reuse some of the functions that get and merge interfaces as well, but I still think you'd need some custom logic for 'virtual chassis'.

This problem will be a bit like contacts I think, I needed to test a couple of different implementations to find one that worked the way I wanted as initial attempts seemed to work but failed when actually used for one reason or another.

[kuhball]

Finally came around to spend some time on this again.

I thought about the merge approach as well and would prefer it. Tried the following things:

• Having all chassis members in one import source and take the virtual_chassis_keyid as keyid - this fails due to duplicated keyids.
• Having one import source for the first chassis member and another for all the additional members.
  • Use one sync rule with update policy "merge" and include both import sources in the sync rule -> f.e. interfaces dict are not merged but overwritten..
  • Use two sync rules with update policy "update only" or "merge" on the second rule. Interfaces dict are not merged but overwritten..

I don't know what else to try or how to debug this. Found this, but no solution.

[sol1-matt]

I didn't think about the duplicate keyid's in the import source but that would indeed be a blocker for merge. You could try and do some fancy filtering over multiple import sources but that seems like a poor way to implement it even if it did work.

There may be a way with import filters, but I've personally never had much luck merging data with import filters, excluding and altering yes, but merging no.

This brings it back to code.

If I was looking to implement this in code, I'd probably start with adding virtual chassis to the import, then using the existing "Link Interfaces" checkbox to get it to read all the interfaces from member. So the UI isn't more complicted (but we'd want the readme to be clear). You might be able to reuse some of the functions that get and merge interfaces as well, but I still think you'd need some custom logic for 'virtual chassis'.

This seems like the best way to get this working. It won't need any new UI elements, just some extra code to detect a virtual chassis and have it get interfaces from the children.

I need to release fb9b6d2. It refactored some of the bits that need to change to implement the virtual chassis interfaces.

[kuhball]

I will wait for you to release and then start implementing.

[sol1-matt]

New release is out @kuhball, v4.4.0.2. I've created a new branch for your PR as well, 66-virtual-chassis which was created from v4.4.0.2.