You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Configure egress access for golden snapshot preparation #2358
Golden preparation may need network access that the actors created from its snapshot should never receive. For example, an RL environment might fetch repositories and datasets during preparation, then run many actors with those files already available and no external network access. Keeping preparation permissions separate from runtime permissions makes that possible.
The golden is a controller-managed actor with its own identity. Since the template already describes how to prepare the golden snapshot, it is also the natural place to declare the network access that preparation requires:
With goldenEgressPolicy, the controller creates the golden actor and its policy atomically, before initialization starts. A separate policy request would require the caller to discover the internal actor and coordinate with its startup. Declaring the policy on the template handles that ordering within the component that already owns it.
I think this is the simplest API for this requirement because it adds one optional field and reuses the existing egress rules, validation, defaults, and enforcement. Actors restored from the snapshot receive their own identities and start without an egress policy, so preparation permissions do not become implicit runtime permissions.
Requiring a full EgressPolicy would also require metadata that the controller already knows how to generate.
Related to #1324 but mostly complementary. Implementation: #2159.
I agree with the problem statement - it's the same as "init" containers.
Embedding it into ActorTemplate is sort of ugly, but... I mean, there's a reason we didn't embed it in Actor but that mostly has to do with scale. I don't think we anticipate having the same cardinality of templates as actors, so scale is probably less of a concern. Also, we don't update templates the way we update actors, so size matters less, again.
So I could probably hold my nose at this. I don't love duplicating the exact schema in 2 places but I guess it is better than trying to do Go embedding and so forth.
Questions:
I assume that an actor derived from this template DOES NOT get that policy in any way?
When we fork an actor from a tag -- do we copy the egress policy? I think not, right?
Assume an Actor is spawn from a golden. It gets the results of whatever downloads the golden did. Later that actor is upgraded to a new OCI image or something - does it need to re-run the "init" phase? Or is it REQUIRED that the golden save data ONLY to durDir. Is there any part of an actor's lifecycle that means it has to re-run init?
Activity
thockin commentedon Oct 9, 2026
I agree with the problem statement - it's the same as "init" containers.
Embedding it into ActorTemplate is sort of ugly, but... I mean, there's a reason we didn't embed it in Actor but that mostly has to do with scale. I don't think we anticipate having the same cardinality of templates as actors, so scale is probably less of a concern. Also, we don't update templates the way we update actors, so size matters less, again.
So I could probably hold my nose at this. I don't love duplicating the exact schema in 2 places but I guess it is better than trying to do Go embedding and so forth.
Questions:
I assume that an actor derived from this template DOES NOT get that policy in any way?
When we fork an actor from a tag -- do we copy the egress policy? I think not, right?
Assume an Actor is spawn from a golden. It gets the results of whatever downloads the golden did. Later that actor is upgraded to a new OCI image or something - does it need to re-run the "init" phase? Or is it REQUIRED that the golden save data ONLY to durDir. Is there any part of an actor's lifecycle that means it has to re-run init?