The Ansible Tower docs states:
“In order to support temporarily taking an instance offline, there is a property enabled defined on each instance. When this property is disabled, no jobs will be assigned to that instance. Existing jobs will finish, but no new work will be assigned.”
https://docs.ansible.com/ansible-tower/latest/html/administration/clustering.html
How do I set an instance property and specifically how do I set this enabled/disabled state property via awx-manage or via command line/API?
Thanks very much in advance,
Mike.
Hi Michael
I don’t have access to the older CLI tools but the newest version doesn’t yet have the ability to modify an instance setting unfortunately.
You can hit the API though with something like:
curl -sku username:password -H “Content-Type: application/json” -X PATCH -d ‘{“enabled”:“false”}’ https://tower_host/api/v2/instances/1/
-k indicates an untrusted SSL connection so you don’t need that if you’ve got a pukka SSL cert in place.
Replace username:password and tower_host with your details
You need to know the instance ID you want modify (1 in my case).
Enabled can be set to true or false
Hope that helps
Phil.
Thanks Phil for the speedy reply!
Can the curl api call use a token instead of u/p?
Also, can I assume one day awx-manage will have that capability?
One of my use-cases I’m exploring is the awx-task node being able to take itself offline gracefully when it needs to and so presently, it has awx-manage. As a temporary solution, it could make a curl call to the API.
I’ve noticed in AWX 9.3 if I call deprovision_instance from the node and shut it down then any jobs it was actively running probably do not finish and AWX reports them as on-going despite the Executor node not being present. I can set a global or template job timeout but the problem I want to solve is receiving more jobs while waiting for existing ones to finish.
I believe from reading the docs and observing this behaviour I need to disable the node from the instance group, allow it to complete current jobs, then shut it down. But keep it part of the Instance Group and talking to AWX to report job status. Is this accurate?
Is there another way to gracefully decommision an awx-task node by letting it finish active jobs and not take on more?
Would deprovisioning and re-provisioning it to the Instance Group immediately and then not registering to a queue work? I see it appears as “unavailable” in the Instance Group but I dont know if it will successfully report back when jobs finish.
Thanks.
Mike.
Yes you can make token calls to the API as well:
Use curl -sk -H “Authorization: Bearer your-token-goes-here” in place of the -sku username:password, after generating the token in AWX
I’m not sure why you want to take an instance offline/online regularly, this is not a common pattern at all. If its cos of network issues, then I’d suggest fixing that instead!
The way we’re heading with automation execution, is a more fire-and-forget type model, where things are spun up on demand using ansible-runner/containers/podman etc
Less things to manage and more dynamism will be great 
Thanks!
Yeah, I am not taking the Task nodes up and down very often… most of the time a small number are running and do not change day to day.
Occasionally (couple of times a month) there’s a need to significantly ramp up our compute platform with intense Ansible jobs… so I’ve been experimenting using an AWX Task in a Docker (9.3.0 awx_web minus nginx) in an AWS ASG to do this efficiently. When the ASG desired is reduces, the AWX Task will disable and deprovision itself after it has completed the current jobs.
I suspect you are working towards something similar but with k8s model? I may well move to this model too in the forthcoming months and move to 11.x.
Checkout what we’re already doing around container instance groups. Point your automation templates at a k8s cluster and it’ll fire up pods, inject necessary config into them and run the automation. Then disappear.
Similar approach to what you’re trying to do, but within the platform capabilities and less external components to manage. This will be developed further over the coming year+ so watch this space