Repository navigation
Add ActorID to the injected actor's process #178
Description
In some cases, it might be useful for the actor to know its own ID. Currently, the only way to determine this is by stripping the incoming request from atenet and extracting the ID from the host name.
Might be expose actor's ID via environment variable or a file on the rootfs?
Activity
bowei commentedon Jun 4, 2026
Env var maybe impossible for vm.
We may consider seeing this information from a metadata server on a link local address as well. This could then be used to write a file etc for ease of use.
feat(atelet): inject ATE_ACTOR_ID into actor process env
juli4n commentedon Jun 5, 2026
I think we need to look at this comprehensively. We need late-binding of configuration within an actor, and it would be nice if we have a single way of doing it. We will need the analogous of projected volumes, at very least config maps, secrets and some downward API (e.g. actor id), but the list will grow (e.g. certificates and OIDC tokens for for actor identity).
dberkov commentedon Jun 5, 2026
I totally agree, we need a generic way to support multiple configurations and we need to build it over time. The #184 is a good start of it. We might need refactor it soon to support additional fields.
+1 for Bowei Du (@bowei) 's suggestion, env variable is not a good solution, we need store in a file.
fkautz commentedon Jun 5, 2026
Would it make sense for me to refactor #184 to be a read only directory and mount it in, rather than mounting the file? Happy to do so.
bowei commentedon Jun 8, 2026
Echoing Julian's comment, we need to evaluate the generic mechanism to be used to project generic information into the Actor. I think the current lead thought is a projected volume, but a couple of things need to be worked through:
feat(atelet): expose actor identity via /run/ate/actor-id
refactor(atelet): mount the identity directory, not a single file
fkautz commentedon Jun 9, 2026
Update: rather than refactoring later, I went ahead and changed #184 to mount a read-only per-actor directory at
/run/ate, with the ID in the fileactor-idinside it. Since the mount shape is now a directory, future late-bound data (more downward-API fields, config, eventually certs/tokens per Julian Gutierrez Oschmann (@juli4n)'s list) can land as sibling files without breaking the contract.To be clear about scope: #184 is not the generic projection mechanism Bowei Du (@bowei) describes. There is no daemon, no metadata service, and nothing refreshed at runtime; atelet just regenerates the directory contents on every resume. The three design questions (runtime compatibility, layout, abuse surface of anything guest-facing) stay open here.
fkautz commentedon Jun 9, 2026
So a question... would it make sense to perhaps have two ways to communicate?
/run/ate/for storing read-only, slowly changing data. Super easy for an app to use: plainopen()/read(), no client library./run/ate/api.sock(AF_UNIX) for anything dynamic, parameterized, or bi-directional. This should be trivial to implement in gVisor (it can ride the existing mount as a host UDS passthrough) and should also work with most hypervisors.For the socket on VM runtimes, the path would probably need to be:
On gVisor there is no agent or vsock hop; the workload's connect goes through the gofer straight to a host socket owned by atelet. The guest agent can be a dumb byte-splicing proxy, with the actual protocol end-to-end between the workload and atelet.
feat(atelet): expose actor identity via /run/ate/actor-id
feat(atelet): expose actor identity via /run/ate/actor-id