Give devices the connectivity view tunnels already have - #186
Merged
Conversation
DeviceStatus only covers enrollment, so the console can show a device as Enrolled but never as reachable. TunnelCredential already models these as two axes; mirror that for devices. Adds DeviceConnectivity plus enrolled_at/last_seen_at. Additive only.
|
The latest Buf updates on your PR. Results from workflow buf-pr / buf (pull_request).
|
vitramir
added a commit
to agynio/users
that referenced
this pull request
Aug 10, 2026
Devices were written pending and nothing ever wrote anything else. Only OpenZiti knows when an enrollment token is redeemed, and users had no liveness poll, so every device read pending forever no matter what it was doing. Adds a poll mirroring the tunnel liveness loop networks already runs: every DEVICE_LIVENESS_INTERVAL it reads GetIdentityLiveness per device and records enrollment and connectivity as two axes, the same shape as TunnelCredential. An unchanged offline device is skipped; an online one is written each pass so last_seen_at keeps advancing. One failing device does not stop the sweep. Needs the Device.connectivity/enrolled_at/last_seen_at fields from agynio/api#186. Also fixes devspace.yaml, which had never run: it patched a deployment named users-users, its pipeline name was invalid for current devspace, it forwarded a host port, and its buf generate was missing the groups proto CI and the Dockerfile both pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DeviceStatusonly models enrollment (PENDING/ENROLLED), so the console can show a device as Enrolled but has no way to say whether it is actually reachable. Devices sit permanently at "Enrolled" once the token is redeemed, even when the machine is off.TunnelCredentialalready splits this into two axes —enrollment_stateandconnectivity, plusenrolled_at/last_seen_at. This mirrors that shape forDevice:DeviceConnectivityenum (UNSPECIFIED/ONLINE/OFFLINE)Device.connectivity,Device.enrolled_at,Device.last_seen_atDeviceStatuskeeps its current meaning as the enrollment axis, so nothing changes for existing readers.Deliberately not adding
provisioning_state: unlike tunnels, devices have no reconcile loop — the OpenZiti identity is created synchronously inCreateDeviceand the row is only written on success, so the field would always readactiveand carry no information.Additive only —
buf lintandbuf breaking --against mainboth pass.Follow-up once this publishes to the BSR:
usersgains the columns and populatesconnectivity/last_seen_atfrom theGetIdentityLivenesspoll it now runs, andconsole-apprenders the second axis.