7 Commits (1355f622beca0db5794201ab8802804ab1299e2f)

Author	SHA1	Message	Date
Brad Fitzpatrick	c2f0c705e7	health: clean up updateBuiltinWarnablesLocked a bit, fix DERP warnings ... Updates #13265 Change-Id: Iabe4a062204a7859d869f6acfb9274437b4ea1ea Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	2 months ago
Andrea Gottardo	b7c3cfe049	health: support delayed Warnable visibility (#12783) ... Updates tailscale/tailscale#4136 To reduce the likelihood of presenting spurious warnings, add the ability to delay the visibility of certain Warnables, based on a TimeToVisible time.Duration field on each Warnable. The default is zero, meaning that a Warnable is immediately visible to the user when it enters an unhealthy state. Signed-off-by: Andrea Gottardo <andrea@gottardo.me>	5 months ago
Andrea Gottardo	309afa53cf	health: send ImpactsConnectivity value over LocalAPI (#12700) ... Updates tailscale/tailscale#4136 We should make sure to send the value of ImpactsConnectivity over to the clients using LocalAPI as they need it to display alerts in the GUI properly. Signed-off-by: Andrea Gottardo <andrea@gottardo.me>	5 months ago
Andrea Gottardo	732af2f6e0	health: reduce severity of some warnings, improve update messages (#12689) ... Updates tailscale/tailscale#4136 High severity health warning = a system notification will appear, which can be quite disruptive to the user and cause unnecessary concern in the event of a temporary network issue. Per design decision (@sonovawolf), the severity of all warnings but "network is down" should be tuned down to medium/low. ImpactsConnectivity should be set, to change the icon to an exclamation mark in some cases, but without a notification bubble. I also tweaked the messaging for update-available, to reflect how each platform gets updates in different ways. Signed-off-by: Andrea Gottardo <andrea@gottardo.me>	5 months ago
Andrea Gottardo	6e55d8f6a1	health: add warming-up warnable (#12553)	5 months ago
Andrea Gottardo	d6a8fb20e7	health: include DERP region name in bad derp notifications (#12530) ... Fixes tailscale/corp#20971 We added some Warnables for DERP failure situations, but their Text currently spits out the DERP region ID ("10") in the UI, which is super ugly. It would be better to provide the RegionName of the DERP region that is failing. We can do so by storing a reference to the last-known DERP map in the health package whenever we fetch one, and using it when generating the notification text. This way, the following message... > Tailscale could not connect to the relay server '10'. The server might be temporarily unavailable, or your Internet connection might be down. becomes: > Tailscale could not connect to the 'Seattle' relay server. The server might be temporarily unavailable, or your Internet connection might be down. which is a lot more user-friendly. Signed-off-by: Andrea Gottardo <andrea@gottardo.me>	5 months ago
Andrea Gottardo	a8ee83e2c5	health: begin work to use structured health warnings instead of strings, pipe changes into ipn.Notify (#12406) ... Updates tailscale/tailscale#4136 This PR is the first round of work to move from encoding health warnings as strings and use structured data instead. The current health package revolves around the idea of Subsystems. Each subsystem can have (or not have) a Go error associated with it. The overall health of the backend is given by the concatenation of all these errors. This PR polishes the concept of Warnable introduced by @bradfitz a few weeks ago. Each Warnable is a component of the backend (for instance, things like 'dns' or 'magicsock' are Warnables). Each Warnable has a unique identifying code. A Warnable is an entity we can warn the user about, by setting (or unsetting) a WarningState for it. Warnables have: - an identifying Code, so that the GUI can track them as their WarningStates come and go - a Title, which the GUIs can use to tell the user what component of the backend is broken - a Text, which is a function that is called with a set of Args to generate a more detailed error message to explain the unhappy state Additionally, this PR also begins to send Warnables and their WarningStates through LocalAPI to the clients, using ipn.Notify messages. An ipn.Notify is only issued when a warning is added or removed from the Tracker. In a next PR, we'll get rid of subsystems entirely, and we'll start using structured warnings for all errors affecting the backend functionality. Signed-off-by: Andrea Gottardo <andrea@gottardo.me>	6 months ago