Script scheduling

[cgb]

Hey @Ylianst thank you for the addition of script running, it seems to be working well and I like the new drag and drop feature also :)

One thing I've been using Scripttask for is to schedule commands to run periodically, and collect/analyse the output as it is stored in the database.

Was wondering if that you had thought about integrating that feature into the new script run capabilities?

[Ylianst]

Yes! I plan to do that. I first want to support getting back the result of a script and storing the result in the event log and display that back. I will then work on script scheduling.

I am on vacation September 7th to October 17th so, I am not sure what the timing for the releases of these feature will be. But that is certainly the plan.

[cgb]

Awesome thank you, completely understand. I logged the issue as I wasn't sure if you were familiar with the scheduling part of Scripttask and maybe your scope was just a interface for running scripts :)

Enjoy your vacation and looking forward to seeing an update in a few months

[Ylianst]

Logging this issue also shows you care about this feature. Nothing worst than coding something no-one will use. So, totally appreciate you taking the time to file it. I am working on testing the new version of the MeshAgent today, if it passes, that will be a big deal. The new agent is much better.

[warlord1312]

Yes! I plan to do that. I first want to support getting back the result of a script and storing the result in the event log and display that back. I will then work on script scheduling.

I am on vacation September 7th to October 17th so, I am not sure what the timing for the releases of these feature will be. But that is certainly the plan.

Would it be possible to store the result in the details tab in a custom field for each script? In the future it would make it easier to export things into a nice report as well versus having it as an event log.

[cgb]

@warlord1312 I analyse the output of the same script running multiple times, so I think each command will need an event timestamp along with other metadata.

For comparison, an example job output from Scripttask:

{
  "_id": {
    "$oid": "XXX",
  },
  "node": "node//XXX",
  "type": "job",
  "runBy": "username",
  "errorVal": null,
  "scriptId": "XXX",
  "queueTime": 1648768204,
  "returnAct": null,
  "returnVal": "C:\\Program Files\\Mesh Agent>ping -n 10 -w 1000 1.1.1.1 \r\n\r\nPinging 1.1.1.1 with 32 bytes of data :\r\nReply from 1.1.1.1: bytes=32 time=550ms TTL=58\r\nRequest timed out.\r\nReply from 1.1.1.1: bytes=32 time=428ms TTL=58\r\nReply from 1.1.1.1: bytes=32 time=511ms TTL=58\r\nReply from 1.  1.1.1: bytes=32 time=325ms TTL=58\r\nRequest timed out.\r\nRequest timed out.\r\nRequest timed out.\r\nRequest timed out.\r\nRequest timed out.\r\n\r\nPing statistics for 1.1.1.1:\r\n    Pac kets: Sent = 10, Received = 4, Lost = 6 (60% loss),\r\nApproximate round trip times in milli-seconds:\r\n    Minimum = 325ms, Maximum = 550ms, Average = 453ms",
  "scriptName": "ping-1111",
  "jobSchedule": {
    "$oid": "XXX",
  },
  "replaceVars": null,
  "completeTime": 1652765314,
  "dispatchTime": 1652765294,
  "dontQueueUntil": 1648768140
}

[warlord1312]

@cgb Can you expand on your exact use case?

I do not want to go off topic here but it may also be helpful to have an alert being sent based on the result of the script maybe?

[crettien]

Logging this issue also shows you care about this feature. Nothing worst than coding something no-one will use. So, totally appreciate you taking the time to file it. I am working on testing the new version of the MeshAgent today, if it passes, that will be a big deal. The new agent is much better.

Hello Ylian, this feature is also of great interest to me and I'll definitely be using it. Thanks for your excellent work!