Handle new action for switching Agent from privileged to unprivileged mode about elastic-agent HOT 6 OPEN

@blakerouse WDYT about replacing the ack'ing mechanism with reporting as part of the check-in payload whether the Agent is running as privileged or not, perhaps as part of the local_metadata field? I'm suggesting this because we've found ack'ing to be unreliable in the past when it came to upgrades and when we implemented upgrade details, we decided to communicate them through the check-in payload and it seems to be working well.

from elastic-agent.

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

from elastic-agent.

I think it would be useful to do a bit of technical definition for this feature, covering not just the responsibilities of Agent but also the associated responsibilities of Fleet UI and Fleet Server so we have a holistic design in place before starting to implement this feature.

from elastic-agent.

⚠️ Important note: Fleet UI users should only be switch Agents from privileged to unprivileged mode, not the other way around.

Switching the other way will technically be impossible but I agree we should make it clear from the UI when we will add this feature there.

from elastic-agent.

To add some details on the technical implementation for this work. The flow of this should work as the following:

1. Upon receiving the action to switch to unprivileged mode the Elastic Agent should store that action into the state store, but NOT ACK it.
2. Then it should perform the elastic-agent unprivileged as a sub-process, ensuring to create the process in a way where when the daemon process is stopped that it will not stop or kill the spawned elastic-agent unprivileged process.
3. elastic-agent unprivileged should then perform the work (understand here there is a chance that if something goes wrong the process is not coming back without manual intervention) this needs to be made clear in the UI
4. Elastic Agent should then restart, read the state store, determine that it has a unprivileged mode action and ACK the action if it is now unprivileged.

from elastic-agent.

@ycombinator Actually that would be better.

from elastic-agent.