Open ryjogo opened 5 months ago
with partial machine config, we could have this applied even in maintenance mode and it defines what events to be notified on
You could do this today by doing talosctl events
API or watching resources. This is not effectively push model, but rather pull model, but it gives more flexibility without putting too much stuff on the OS.
You get the data, but what you do with it (how you notify and what) is up to you.
E.g. you could do equivalent of talosctl get machinestatus -o yaml -w
and figure out machine status.
@smira Thanks, this is also an option - but with thousands of nodes, we'd have to subscribe to events on everyone, including any new ones that popup/get torn down. It would be beneficial to de-couple this process to a push model then we wouldn't have to manage "state"
This is where SideroLink comes handy, and it helps in many other ways as well.
Feature Request
Description
It would be fantastic if one could utilize “hooks” that can fire at certain points in the bootstrap process. Perhaps just before and after the bootstrap we can trigger events, example notification of nodes being provisioned to external systems etc.
This could be extended to other parts of the system, i.e upgrades, resets, or any other API changes.
Support for a simple payload of metadata from the Talos API, i.e. OS Version, network information could be a stretch goal.
For a conversation on the matter: https://taloscommunity.slack.com/archives/CMARMBC4E/p1715857612529299
Use case
Our use case would simply be to report when a node is being bootstrapped, and was successfully bootstrapped, like a start/end of a bootstrap process, of course this would need to have the network up and running to send a POST request to an external endpoint.
Other use cases could be to improve actions or run secondary workflows based on the triggers. I.e, if a node was reset or successfully upgraded - from/to which version.