Forum Discussion

Cole_McDonald's avatar
Cole_McDonald
Icon for Professor rankProfessor
2 years ago

Automatic removal of category

We have a piece of software that ran as a service we used to monitor.  To make sure the dataSources were pointed correctly, we have a propertySource that adds a category.  We’ve since moved away from...
category
propertysource
  • Anonymous's avatar
    Anonymous
    2 years ago

    Categories should be deprecated. <<EOL>>

    You can’t remove them just by removing their PS. This leads to AppliesTo in PS that look like this:

    isCisco() && !hasCategory("myCategory")

    Which is confusing since myCategory is the one you want to add. But to speed up performance, having this in the AppliesTo means that the PS doesn’t run again for that device once the category is set. This is complicated but makes sense since there’s no need to set the category once the category is set, and NOT running it again won’t remove it.

    The other problem is that you can’t ever tell where a category came from. Which PS set it, why? Did someone add the category manually? FEED-13368

    I have been asking (FEED-13369) for a built in mechanism that will allow individual properties to turn on/off specific datasources. For example, if you add `ping.disable = true` it would disable the Ping DS without needing to update the AppliesTo of the Ping DS to account for it. This would be extensible, working with any datasource, even custom ones. If `<ds_name>.disable = true` is on the resource, it would disable <ds_name> for that device. `<ds_name>.enable = true` would do the opposite. With this logic, you’d be able to write property sources and combine them with manual properties using inheritance to enable it on exactly the devices you want (not to mention inheriting from dynamic groups potentially obviating the “addCategory” propertysource altogether). All this would require is an implicit addition to every appliesto:

     && (![ds_name].disable == "true" || [ds_name].enable == "false")

    This is a change that could be done on the back end today without any impact. Then AppliesTo could be updated piecemeal over time, bringing them into compliance. This addition to the AppliesTo could also be displayed next to the existing AppliesTo, helping the admin know that it’s there and how that logic plays in. It could also be used to shortcut the AppliesTo of new logicmodules, making it possible to enable it manually on one device easily without ever having to learn AppliesTo scripting.

mnagel's avatar
mnagel
Icon for Professor rankProfessor
2 years ago

LM has no option for automatically removing category elements, only adding them.  It is just one of many poorly thought out core system features we’ve run into over the years.  My workaround was to add checks to our crosscheck script to detect various problems. For example, if a Windows server is no longer running DHCP, we get a warning from the script (e.g., “category is set but no DHCP service found running”). It could be more aggressive and actually change the system.categories value via the undocumented (and frightening) debugger API, but so far the warnings have been sufficient to at least stay on top of these issues.