Schedule server updates/reboots using API calls.
Hello,
I'm in the process of trying to schedule update/reboots using API calls. I was wondering if any one else has tried doing something similar. Any help is much appreciated.
-Eric
Responses
Hello, Job invocations is the key term.
have a look at http :// your_sat6 /apidoc/v2/job_invocations/create.html
HTH
Are you looking for something in particular? We use the API to schedule errata application and reboots monthly. There's quite a bit of documentation in the link Stephen mentioned above, as well as tools such as nailgun which might make it easier for you.
For a sample API , you can do something like this:
def schedule_reboot(host_name,reboot_time):
data = json.dumps(
{
"job_invocation": {
"inputs": {
"action": "restart"
},
"job_template_id": 75,
"targeting_type": "static_query",
"scheduling": {
"start_at": reboot_time
},
"search_query": "name = " + host_name
}
})
r = post_json(SAT_API + "/job_invocations", data)
schedule_reboot(host['host_name'],reboot_time)
And we use a custom job template for applying errata since the current stock one is broken for installing errata on RHEL6 (uses advisories (not supported in rhel6 yum) instead of advisory )
def schedule_apply_errata(template_id,errata_list,start_time,members):
data = json.dumps(
{ "job_invocation": {
"inputs": {
"errata": errata_list
},
"job_template_id": template_id,
"targeting_type": "static_query",
"scheduling": {
"start_at": start_time
},
"search_query": "name = " + query
}
})
Most definitely. We patch by host collection or union/intersection of multiple host collections. We have a script that you feed json too with your patching parameters and it goes off and does the api magic to schedule errata application at random times between the window, and reboots at the appointed reboot time
the json looks similar to this:
{
"env": "unit", <-- Matches to a host collection
"start_time": "2017-01-21 05:00:00",
"reboot_time": "2017-01-22 02:10:00",
"end_time": "2017-01-21 21:00:00",
"time_span": "4800",
"errata_type": "security",
"cm_number": "<change ticket>"
}
Most definitely. I've been using the same basic script structure for our Satellite 5 environment for the last four years. I rewrote it for Satellite 6, but kept a lot of the same basic logic. Satellite 5 never lent itself to recurring logics, however I will say, you should look into 'recurring logics' in Satellite 6 as I believe it can be used to schedule these repetitive tasks (patching, etc) fairly efficiently.
I like having the external scripts as we call them from our "toolbox" which handles errata merging (publishing / promoting from Library to LAB to PROD, reporting, scheduling and a multitude of other admins functions from a single pane..
I'm not a programmer by any stretch, but if you need help as you guy I'm happy to try to help out.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
