limit servers by variable

[lgwapnitsky]

I may not be explaining myself clearly, but I'd like to trigger a job on a specific server by specifying a variable with the server's name. How can I limit the servers on which my process runs?

[jhuckaby]

Hello!

Well I'm not sure exactly what you mean, but if you are using the UI, you can target an event to run on any individual server you like. The "Targets" menu has both groups, and individual servers in it:

But if you are using the API, specifically the run_event API, then you can run an existing event job on any server you want, by overriding the Event.targets property per each run_event API call:

{
    "id": "EVENT_ID_HERE",
    "targets": ["SERVER_ID_HERE"]
}

Example using curl:

curl -X POST "http://YOUR_XYOPS_HOST:5522/api/app/run_event/v1" \
    -H "X-API-Key: YOUR_API_KEY_HERE" \
    -H "Content-Type: application/json" \
    -d '{ "id": "EVENT_ID_HERE", "targets": ["SERVER_ID_HERE"] }'

For this you will need to know the Server.id, which is available on the server details page:

Note that this doesn't update the event itself -- it just runs a job for event with custom overrides -- in this case the targets.

Hope this helps!

[cju-mt]

Feature Request: Per-Satellite Data Store ("Satellite Buckets")

Right now there's no way to attach data to a satellite that jobs can act on — whether for targeting decisions or as variables passed into scripts running on that satellite. Server groups get you part of the way there but they're static membership lists, not properties of the satellite itself.
The idea is a simple key-value store per satellite — some of it persistent (location, environment, capabilities) and some writable at runtime for temporary state or dynamic assignments. Job targeting could then filter on those values, and scripts could reference them directly, without needing external workarounds.
Tools like Salt (grains), Ansible (host variables), and AWS (instance tags) all solve this the same basic way — the server carries data about itself and the orchestrator can act on it. xyOps doesn't have an equivalent as far as I can tell.
I migrated from Cronicle and currently use Salt to fill these gaps. It works, but it would be great to handle more of this natively within xyOps over time.

Thanks :)

[jhuckaby]

Wow, this is a great one! Thanks, adding to the TODO list!

[jhuckaby]

I moved this to its own feature request: #160