Standardize NATS subjects

[paulgb]

We should standardize subjects as follows:

cluster.<cluster_name>.*: cluster-level messages cluster.<cluster_name>.drone.<drone_id>.*: drone-level messages cluster.<cluster_name>.drone.<drone_id>.backend.<backend_id>.* backend-level messages

This allows us to permission pub/sub to various levels: cluster-wide, drone-wide, backend-only. It also means that all backend-level messages will need a cluster and drone field, and all drone-level messages will need a cluster field (because of our rule that the subject must be derived from the message itself).

[paulgb]

Proposed changes:

	Current	New	Usage
agent.rs
DroneLogMessage	backend.{backend_id}.log	cluster.{cluster_id}.backend.{backend_id}.log	Report a log message that comes from a backend. backend_log stream.
BackendStatsMessage	backend.{backend_id}.stats	cluster.{cluster_id}.backend.{backend_id}.stats	Report current backend usage. Used for metering.
DroneStatusMessage	drone.{drone_id}.status	cluster.{cluster_id}.drone.{drone_id}.status	Used for reporting drone availability to scheduler. Also appears on dashboard.
DroneConnectRequest	drone.register	cluster.{cluster_id}.announce_drone	Rename to DroneAnnouncement. Currently includes IP of drone which is used for routing, but once Spawner DNS is implemented this will just be used for logging. Maybe this becomes a regular log message?
SpawnRequest	drone.{drone_id}.spawn	cluster.{cluster_id}.drone.{drone_id}.spawn	Tells a drone to run a backend which has already been scheduled to that drone.
TerminationRequest	backend.{backend_id}.terminate	cluster.{cluster_id}.backend.{backend_id}.terminate	Tells a drone to terminate a backend.
BackendStateMessage	backend.{backend_id}.status	cluster.{cluster_id}.backend.{backend_id}.status	Emitted when a backend changes state. Rename BackendStatusMessage?
cert.rs
SetAcmeDnsRecord	acme.set_dns_record	remove (#226)	Rename to SetDnsRecord, support A (and eventually AAAA) records?
dns.rs
SetDnsRecord	new (#162)	cluster.{cluster_id}.dns.{A/TXT}	Replaces SetAcmeDnsRecord and also supports A records.
logging.rs
LogMessage	logs.controller, logs.drone.{}	cluster.{cluster_id}.logs.{}.{}
scheduler.rs
ScheduleRequest	cluster.{cluster_id}.schedule	cluster.{cluster_id}.schedule

Notes:

• We should standardize on “state” to refer to a state-machine state, and “status” to refer to state plus load information, metadata, etc.

• SetAcmeDnsRecord will become a generic SetDnsRecord message for setting a DNS record that supports TXT and A records. Drones will announce every drone they are running on an interval, and the DNS server should pick these up, cache them locally, and serve them (#119).

• Draining (#129) will work by sending a message to cluster.{cluster_id}.drone.{drone_id}.drain, at which point the Drone will report in its status updates that it is draining and the scheduler will no longer schedule to it.

[pretentious7]

Hmmm yea I like the SetDnsRecord idea, writing the commit for that right now. I think maybe change BackendStats to BackendMetrics? easier to tell apart from status visually, plus status and stats and state all have too many letters in common.

[pretentious7]

I'd like some way to set the nats level permissions in the rust code.

[paulgb]

There’s a promising lib for it: https://docs.rs/nats-jwt/latest/nats_jwt/

We need to figure out where it lives, though. If we provide JWT signing over NATS, we would need to connect, get a JWT, and then reconnect with that JWT.

— Paul

On Thu, Sep 22, 2022 at 11:31 AM pretentious7 @.***> wrote:

I'd like some way to set the nats level permissions in the rust code.

— Reply to this email directly, view it on GitHub https://github.com/drifting-in-space/spawner/issues/145#issuecomment-1255400293, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALIXPWEV27WXOJMXIELP3V7SQXXANCNFSM6AAAAAAQELX6KI . You are receiving this because you authored the thread.Message ID: @.***>