Closed noahtalerman closed 8 months ago
Noah: I wonder if we can crank the cooldown down to like 1 hr and see if it works (instead of 24)
Discussed during product design check-in call (recorded) 2024-01-19:
Mike: Let's make sure to interrogate the error and make sure this is the rate limit error. We want to avoid swallowing other errors and introduce a bug in which we surface a bunch of false positives.
Pseudo code for interrogation.
try { doSomething() } catch (err) { if (err.isRateLimitError) { …} else { throw err; } }
cc @georgekarrv @roperzh
@noahtalerman I don't think we have verified if this is a rate limit error! I also don't think we have any way to know from the info that's provided to us.
The only thing we know for sure is that some hosts are failing the profile assignment (we can know which hosts) and we're not surfacing that information anywhere.
Hey team! Please add your planning poker estimate with Zenhub @gillespi314 @jahzielv @roperzh
Context: 2 macOS hosts assigned to my instance via ABM, neither enrolled.
Observations:
Error icon is immediately visible next to the MDM status from the moment Fleet picks it up as a Pending
ADE host.
However, I observed this state on 2 separate hosts. Upon attempting to enroll both, I noted that one in fact had failed to assign ADE profile & proceeded through setup without enrolling. The second enrolled successfully, yet the error remained:
It is unclear if there is a timing issue for the error state to eventually clear, however that is moot given that this host should not be displaying an error.
@noahtalerman we need some input from you on this. The issue is this—we are displaying errors on the MDM status for hosts that are already successfully enrolled On (automatic)
in addition to hosts that are Pending
, so it is currently impossible to tell from a glance if an enrollment profile has failed or not, essentially defeating the purpose of this ticket.
Based on my conversations with Sarah, the error that we are displaying for enrolled hosts is not technically incorrect, because (as is outlined in #17291) we are constantly re-assigning profiles, so it is entirely possible for an enrolled host to have a failed profile assignment.
The proposed solutions are:
I've moved this to Ready, marked it blocked, and added the :product
label to ensure that we get these qiestions answered before releasing.
Consider this blocked until 17291 gets merged in, and retest to see if the fix also addresses the errors here.
@sabrinabuckets and @gillespi314 I think we should go w/ this option. Nice catch BTW
Otherwise we're creating too much noise. The IT admin only cares about the DEP profile failing when they want the DEP profile to change.
Fix the painfully vague tooltip copy
What do y'all think the tooltip should say?
@sabrinabuckets I merged a fix for #17291, so I'm moving both issues to awaiting QA
With #17291 resolved, I am no longer seeing the errors on enrolled hosts.
API docs PR is here: #16166
@Patagonia121, heads up, this customer request was shipped in Fleet 4.47 🔥
In Fleet's glass city, Mac hosts that failed now seen, Admins sigh relief.
Goal
Changes
Product
profiles show -type enrollment
to see which DEP profile is current applied to the host. UPDATE: Let's not increase the docs surface area for this. If we want to add this instruction to the UI, let's file a feature request (noahtalerman 2024--03-15)Engineering
Context
QA
Risk assessment
Manual testing steps
Testing notes
Confirmation