command line interface

BatchPatch Forums Home Forums BatchPatch Support Forum command line interface

  • This topic has 4 replies, 2 voices, and was last updated 3 years ago by bc2022space.
Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #13265
    bc2022space
    Participant

    Does anybody know if batchpatch supports command line arguments? or an api while it is running?

    I’d like to be able to link bp with an external scheduler that can handle more complex update tasks with dependencies.

    Thanks

    #13266
    doug
    Moderator

    BP does not support command line arguments. There is no API.

    That said, BP can handle a lot of dependency situations etc, generally with much more flexibility than an external scheduler. If you describe specifically what you’re trying to do or accomplish, I can let you know if/how you can do that in BP.

    #13267
    bc2022space
    Participant

    I need to

    Schedule a group of 100+ servers to update in sequence 1 at a time:

    send email,
    verify failover server is available from sql database or file logs, verify no users active, stop services on original, do updates and reboot,
    verify services started again from sql db or file logs, fail back and verify again, send email. Cannot move on to next server until success.

    I need the scheduler to keep the tasks list indefinitely across all the servers and have a monthly recurrence.

    This all probably could be done using the existing gui but using a script would make this much easier to manage.

    The job queue seems to be designed for a single pc or smaller number of computers.

    The row execution interval assumes the computers can be sorted in the correct order of execution, which also doesn’t work for me.

    #13268
    doug
    Moderator

    You can do this with BP. I would recommend using the ‘Advanced Multi-Row Queue Sequence’. It works in conjunction with the job queue to enable you to orchestrate a sequence across numerous hosts, with whatever dependencies etc. Here are a handful of tutorials/examples, so you can see how it works:

    https://batchpatch.com/advanced-multi-row-queue-sequence-video-tutorial

    https://batchpatch.com/orchestrating-complex-update-and-reboot-sequences-involving-multiple-target-computers

    https://batchpatch.com/advanced-multi-row-queue-sequence-staggering-updates-and-reboots-in-a-group-of-computers

    https://batchpatch.com/advanced-multi-row-queue-sequence-contingent-operations-with-custom-scripts

    https://batchpatch.com/custom-update-and-reboot-sequences-for-multiple-computers

    https://batchpatch.com/virtual-machine-guest-host-update-and-reboot-sequence-automation

    https://batchpatch.com/advanced-multi-row-queue-sequence

    If, as you mentioned, this would all be much easier to do with a script, what role would you have BP play at all? I mean in that case why not just do it all with a script and not involve BP at all? I’m curious to understand what you had in mind for the role that BP would play (I mean if BP had a CLI/API). It helps for us to understand this kind of thing so that when we are deciding on new features etc, we have an idea for the expectation people have for how things would work. In the particular case that you described, I think perhaps you just weren’t aware of the advanced multi-row queue sequence, which will enable you to do the things that you described. However, if after reviewing the advanced multi-row queue sequence functionality you still believe that your process is better suited to all be manually scripted, then I’d be interested to know specifically which actions you would have BP performing in that process vs which actions you would find preferable to not use BP for. Thanks.

    #13269
    bc2022space
    Participant

    I was simply hoping for a way to not write my own library to run psexec since we already have a batchpatch license. I will give the advanced multi row queue a try.

    Thanks!

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.