Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Report "connected to Peer" status for each Gateway #4738

Closed
Tracked by #3514
jamilbk opened this issue Apr 22, 2024 · 4 comments · Fixed by #4931
Closed
Tracked by #3514

Report "connected to Peer" status for each Gateway #4738

jamilbk opened this issue Apr 22, 2024 · 4 comments · Fixed by #4931
Assignees
@conectado
Labels
area/connlib Firezone's core connectivity library business_value/high Required by > 50% of our customer base kind/feature New feature or request kind/UX Changes related specifically to overall user experience and product quality

Comments

@jamilbk
Copy link
Member

jamilbk commented Apr 22, 2024 •
edited

It would be helpful to know whether a Resource has:

  • a Peer (Gateway) connected
  • Peer not connected/attempted yet
  • "Resource Offline" peer unavailable

These will be used to show status indicator dots in the Client UI for each resource.
@jamilbk jamilbk mentioned this issue Apr 22, 2024
Open
10 tasks
@jamilbk jamilbk added kind/feature New feature or request area/connlib Firezone's core connectivity library kind/UX Changes related specifically to overall user experience and product quality labels Apr 22, 2024
@jamilbk jamilbk assigned jamilbk and unassigned jamilbk Apr 22, 2024
@jamilbk jamilbk added the business_value/high Required by > 50% of our customer base label Apr 22, 2024
@conectado
Copy link
Collaborator

I was planning to set this on the set_resources call.

There are still a few questions.

  • When do we count a "resource" as connected? When we request and succeed on establishing a connection for that resource or when we have a connection for a gateway that is in the same gateway-group as that resource? In the latter case we might get a false positive, since we don't know until we try when implement dynamic policies.
  • In the same line of questioning, when do we count a resource as offline? When we particularly tried to connect to a resource but got an offline response or when we get an offline response for any resource with the same gateway-group?
  • For how long does a resource count as offline? until we retry connection or is it cleaned up at some point?

For now I'll go with the easiest to implement, which is only show status after trying connection for specific resources and only switch status when we get a response(important for the offline case!)

@conectado
Copy link
Collaborator

If the data-plane fails either, can't make a connection or the connection times-out should we count that as:

  • Offline
  • Unknown
  • Or a new status?

I think a "Failed Connection" status might be good to debug for us but I feel it might make it hard for the user to understand the difference.

@jamilbk
Copy link
Member Author

jamilbk commented May 7, 2024

Hmm, I think the main purpose behind this issue was to make it clear to the user (possibly a power user) when it's not possible to connect to any Resources in the Site. I.e. to reflect the "Resource Offline" message from the portal (which isn't entirely accurate -- it's more like a "Site offline" error, right?).

If that's the case, we should be tying this status to the Site, and not Resource. I'll have to think more about how to reflect it in the UI, but what do you think of this approach:

  • Active peer connection to Gateway in Site: Site online
  • "Resource offline" message -- Site offline. Keep status for the same time period as Sleep connections after inactivity #4549 until it's reconfirmed by another access attempt, or changes to online from a successful access attempt
  • No status -- "Site not connected" or similar

Would that work?

@conectado
Copy link
Collaborator

Hmm, I think the main purpose behind this issue was to make it clear to the user (possibly a power user) when it's not possible to connect to any Resources in the Site. I.e. to reflect the "Resource Offline" message from the portal (which isn't entirely accurate -- it's more like a "Site offline" error, right?).

If that's the case, we should be tying this status to the Site, and not Resource. I'll have to think more about how to reflect it in the UI, but what do you think of this approach:

* Active peer connection to Gateway in Site: Site online

* "Resource offline" message -- Site offline. Keep status for the same time period as [Sleep connections after inactivity #4549](https://github.com/firezone/firezone/issues/4549) until it's reconfirmed by another access attempt, or changes to online from a successful access attempt

* No status -- "Site not connected" or similar

Would that work?

I think for most cases this works until we have multi-site resources

@conectado conectado mentioned this issue May 9, 2024
Merged
@jamilbk jamilbk changed the title Report "connected to Peer" status for each Resource Report "connected to Peer" status for each ~~Resource~~ Gateway May 13, 2024
@jamilbk jamilbk changed the title Report "connected to Peer" status for each ~~Resource~~ Gateway Report "connected to Peer" status for each Gateway May 13, 2024
github-merge-queue bot pushed a commit that referenced this issue May 15, 2024
@conectado
feat(connlib): report resource status to client (#4931)
a7d35cd 
This PR introduces site's `Status`. That's used to report to the client
the status, either, unknown, online or offline, mostly as a hint to
users as what's wrong with a connection.

This are the criteria for an online or offline resource

* If all sites related to a resource are offline the resource is
considered offline, since there's no gateway that can respond to that
resource's connection
* If any site is online the resource is online, since that same peer can
be used to reach that resource
* Any other case is unknown

Right now resources are single site so it doesn't matter too much but
tracking online/offline per-site instead of per-gateway or resource
seems like the better long-term solution.

The way to "find out" the site's status is:

* If a response to a connection details is offline, all sites related to
that resource must be offline otherwise there would've been a gateway in
the response
* At the point we connect to a gateway, the site that corresponds to
that gateway must be online
* When a connection to a peer stops it's considered unknown again

Fixes #4738
jamilbk pushed a commit that referenced this issue May 15, 2024
@conectado @jamilbk
feat(connlib): report resource status to client (#4931)
9724d1e 
This PR introduces site's `Status`. That's used to report to the client
the status, either, unknown, online or offline, mostly as a hint to
users as what's wrong with a connection.

This are the criteria for an online or offline resource

* If all sites related to a resource are offline the resource is
considered offline, since there's no gateway that can respond to that
resource's connection
* If any site is online the resource is online, since that same peer can
be used to reach that resource
* Any other case is unknown

Right now resources are single site so it doesn't matter too much but
tracking online/offline per-site instead of per-gateway or resource
seems like the better long-term solution.

The way to "find out" the site's status is:

* If a response to a connection details is offline, all sites related to
that resource must be offline otherwise there would've been a gateway in
the response
* At the point we connect to a gateway, the site that corresponds to
that gateway must be online
* When a connection to a peer stops it's considered unknown again

Fixes #4738
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@conectado conectado

Labels
area/connlib Firezone's core connectivity library business_value/high Required by > 50% of our customer base kind/feature New feature or request kind/UX Changes related specifically to overall user experience and product quality
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(connlib): report resource status to client firezone/firezone
2 participants
@jamilbk @conectado