need method to set properties in groovy code

Some possible workarounds:

I think LM Config might be the better option for this, although I haven't played with it personally yet. It's designed for config files, but I don't see why the "config" file can't just be the version info.

Also rather than attempt to use properties to store state, you can try using a file on the collector, for example "../tmp/firmware_${hostname}.LastRun" then it would be easy to read in the script. There might be an issue if resource bounces around collectors though.

You might also be able to using Auto Discovery Instances with DataSources, which lets you set auto properties, but that might be tricky to implement.

There are at least two reasons why not to use LMConfig.  First is cost -- it is a premium feature and as applicable as it might be here, it is insane to invoke an extra charge to get this basic concept implemented.  Second (more important) is that LM does not actually tell you what changed.  We work around this via the API to download, commit to a git repo and use a hook to get email on changes.  That could also work, but again seems like a lot to ask of users.

The file storage method could work, but if there is a collector failover or change you lose state.  Building redis or similar into the toolset would help with this sort of thing.

On 10/18/2019 at 5:12 PM, mnagel said:

If there could be a hostProps.set method, that would be very helpful. 

+1 from me.

I might be misunderstanding what you are trying, but why can't you convert the firmware version into a number, and alert on if it changes?

Perhaps, but not everything in version strings can easily be converted into a number.  It might be a good enough workaround in this particular example (will see if I can make it work).  We still need to be able to manipulate actual strings sometimes so this facility is still desirable.

You could set a property for the intended version (as a string), then use groovy to compare the current value to the intended value and return a 0|1. I'm not positive it would work without groovy, but you theoretically could do it without groovy and just look for the presence of a string matching a token. Groovy would def work though.

Sure, that would work, but would be super maintenance intensive.  I am just trying to do something SolarWinds can do out of the box, but as I often find, there are walls up all over the place :(.

Yeah, if you don't want to pay for the tool specifically designed to do it, you get workarounds that are usually intensive/clunky.  LM can also do it out of the box: LMConfig.

That said, what's the pain you're trying to solve? Are you trying to know which devices are on which firmware? Are you trying to catch when someone upgrades a device without you knowing? You could do a property source to get the firmware (if it's not already there) and create auto-populated group(s) on the desired firmware(s) and another where the firmware isn't what you want it to be.  For that matter, regarding my previous though around building a datasource and comparing against properties, you could so something similar. Use a property source that runs only once a day to automatically generate ##intended.version##. Then run the DS more frequently comparing current to ##intended.version##. Differences would result in a value that could open an alarm.

LMConfig is wrong for several reasons (which I thought I addressed earlier):

  * it is a premium feature that may not be subscribed to and if the only option here, a very large mallet for a simple problem
  * LMConfig does not report changes (we workaround this via API grabs with git email-on-push integration, but this is not a general solution for folks)

Again, this is the example that caused me to think of how to best solve the problem -- another client uses SolarWinds and they get a notice when the firmware version changes.  With strings and everything.  I thought of a way to solve it that would buy us all a general improvement and hostProps.set was the answer.  I'll take others, but LMConfig is not it.

As far as a general table of results, that would also be awesome.  Unfortunately, the only option for that is reports since dynamic tables cannot present properties, only numeric datapoints.  Reports cannot be embedded in anything, including email, so they can't work for that.  It would be super cool to have stuff like that in a widget with a bonus if there was a "changed recently" colorization option or even just a sort by change date.