CrowdControl.Provider.Endpoint (crowd_control v0.1.0)

Copy Markdown View Source

How to reach one sandbox's sandboxd agent, right now.

Produced by CrowdControl.Provider.acquire/1 and CrowdControl.Provider.reconnect/1, consumed by CrowdControl.Backend.Sandboxd.API, and never persisted — see the third load-bearing contract in CrowdControl.Provider.

Every field here is ephemeral for a different reason:

  • base_url — a loopback port assigned per-connection. Docker publishes the agent on 127.0.0.1:0 and the daemon picks the port; a GCE tunnel opens a fresh local listener each time. Persisting it means reattaching to whatever else claimed that port.
  • token — derived, not stored. See CrowdControl.Provider.token/1.
  • headers — extra request headers, merged over the authorization header built from token. This exists so a provider whose transport already claims authorization (the Kubernetes API server's pod proxy) can say so, rather than the transport silently sending the wrong credential.
  • req_options — transport-specific Req options: :unix_socket, :connect_options, custom CA certs. Merged into Req.new/1 by CrowdControl.Backend.Sandboxd.API.
  • transport — a resource whose lifetime equals the endpoint's, such as an :ssh connection ref for a forwarded port. Closed by CrowdControl.Provider.release/1. A pid or ref here is precisely why this struct cannot round-trip through :erlang.term_to_binary/1 usefully.

Inspect is overridden to redact token and headers, because endpoints end up in Logger metadata and error tuples on every failure path.

Summary

Types

t()

Types

t()

@type t() :: %CrowdControl.Provider.Endpoint{
  base_url: String.t(),
  headers: [{String.t(), String.t()}],
  req_options: keyword(),
  token: String.t(),
  transport: term()
}