Forum Discussion

Cole_McDonald's avatar
Cole_McDonald
Icon for Professor rankProfessor
9 months ago
Solved

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 and uninstalled that software, but the category persists.  We have a few other cases as well, servers that were migrated from Azure into our dataCenter that are still tagged as AzureVM, etc.

Has anyone found a good way to automatically remove a category or does this remain a manual process?

category
propertysource
  • Stuart_Weenig's avatar
    Stuart_Weenig
    9 months 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.

2 Replies

Sort By
  • Stuart_Weenig's avatar
    Stuart_Weenig
    Icon for Legend rankLegend
    9 months 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
    9 months 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.