[Feature Request]: Allow seed-param for xySat (docker) installations

[peterbuga]

Is there an existing feature request for this?

• I have searched the existing issues

What is your feature request?

This is a cross-dependent request related to https://github.com/pixlcore/xysat

The issue/flow: I like to update infra using docker tags (and not using latest) to have a better view of what's actually running.

As much as I like the new ability to upgrade the workers and coductors all from xyOps interface it's prone to have a mismatched status, for example: using ghcr.io/pixlcore/xysat:v1.0.11 and then triggering an internal update that brings xySat to v1.0.12 getting docker-tag != runner-version.

I'm using XYOPS_setup to provision the workers and every time the container is recreated a new config.json is created with a new server_id + auth_token.
currently, as a patchy-situation, using a custom start-script I'm storing the very 1st config.json and then when container is recreated I'm just swapping server_id + auth_token in the newly-pulled config.json to make sure it also grabs the latest changes from xyOps.

One possible solution on xyOps side: allow for an extra param in /api/app/satellite/config?t=KEY to "seed" the generation of server_id + auth_token so they return always the same values.

Alternatively on xySat side, allow for a bit more dynamic config.json (I can open an issue on xySat side if makes more sense either of these):

• ability to have a custom config.json path
• env variables for server_id + auth_token
• store server_id + auth_token in a docker named-volume to be swapped (if present) every time a curl $XYOPS_setup is executed.

Another quick option would be to have 1-server-group defined on xyOps side for each target, this way newly created worker servers post-update will always be targeted properly but this leaves zombie-servers that need to be constantly cleaned.

As always, thanks for your work 🙏!

Code of Conduct

• I agree to follow this project's Code of Conduct

[jhuckaby]

Hmmm, an interesting problem here!

Okay, so first let me just ask this. Your workaround here raised my eyebrow:

currently, as a patchy-situation, using a custom start-script I'm storing the very 1st config.json and then when container is recreated I'm just swapping server_id + auth_token in the newly-pulled config.json to make sure it also grabs the latest changes from xyOps.

So, Satellite will ONLY run the "first launch" bootstrap XYOPS_setup thing, if and only if the local config.json file is either nonexistent, or has zero-bytes:

https://github.com/pixlcore/xysat/blob/main/container-start.sh#L7-L12

So, if the file exists and has a non-zero size, the entire bootstrap config setup is SKIPPED, and it preserves the existing file in place.

Could this logic work for you? I guess what I am saying is, if you bind-mount the config file, and map it to a folder on your host, then a Docker container upgrade of satellite should preserve the config file?

Separately, regarding this item:

env variables for server_id + auth_token

This already exists now, in fact. xySat allows environment variables to override ANY property in the configuration file, using this syntax (basically just a XYSAT_ prefix):

XYSAT_server_id="YOUR_SERVER_ID"
XYSAT_auth_token="YOUR_AUTH_TOKEN"

Does that help your situation at all?

[peterbuga]

So, Satellite will ONLY run the "first launch" bootstrap XYOPS_setup thing, if and only if the local config.json file is either nonexistent, or has zero-bytes:

I guess my problem with this approach is that the config.json won't refresh anymore with new information from xyOps after an initial setup.

Also, I just noticed the [ ! -s "config.json" ] in the logic, which in theory could allow me to bind-mount an empty file to /host/empty-config.json:/opt/xyops/satellite/config.json and let the setup kick in and write the info into it that'll survive container updates.

IMO this is not the best scenario, normally one will bind a folder or maybe named-volume and write config.json into that one, but in this case config.json being in project-root will the other files blocks this option. having it like /opt/xyops/satellite/config/config.json will solve half the problem.

This already exists now, in fact. xySat allows environment variables to override ANY property in the configuration file, using this syntax (basically just a XYSAT_ prefix):

Small facepalm-moment here, I've been using XYOPS_ env vars but didn't think they'll be available for xySat too (couldn't find in documentation, sorry I missed it).
I don't have a huge fleet of workers so I think I'll go with this option, this way I can have both of my problems solved: refreshing config.json settings served by xyOps + keeping a constant server_id & auth_token per server.

I do still think that having config.json generate/refresh only once the worker is setup by default and the fact that you might need some day to push a new key-value information for xySat, feels like a small ticking-bomb or force you to implement a refresh option on xySat side (unless it exists already and I'm unaware of it 😅)

I'll test out scenario above and close the issue later on as it seems to fit my needs.