Closed shekohex closed 1 month ago
I don't know if I think having a different mode is the route IMO. I see it being simpler if you just
Simple as that, no need for too much alt branching in the code.
@drewstone
we download binary and execute registration function immediately.
How would the gadget binary know which function to execute? i.e The shell manager want to call the registration
function on the binary, how would that work in your opinion? I may be missing something here.
Overview
A simple call (similar to
services.register
) that does signal our interest in registering on this blueprint. It only emits an eventPreRegistered { operator, blueprint_id }
so that the shell could consume this event, download the gadget binary and execute it in the Registration Mode*.Gadget Registration Mode
Normally, running the gadget will start the event watcher and watch for
JobCalled
events, that way it will execute jobs. However, running the gadget binary withREGISTRATION_MODE=on
should instead do the actual registration process. In some sense, the shell manager will execute the gadget normally, but setting theREGISTRATION_MODE=on
env to that process indicating that this gadget should run the Registration function instead of listing for jobs.Why?
The mean reason behind this call is so that to automate the registration process; from the perspective of the operator; simply by calling
services.pre_register()
extrinsic it will emit thePreRegistered
event that will be picked by the shell-manager to continue the process. This avoids going through SSH to the box or registering manually.