Desktop Offering View in Automate

[nataliesea]

What problem are we solving? To support the Desktop offering launch Automate will be creating a visual Dashboard specific to users of Desktop. This view is meant to provide the logged in user to be able to fulfill the following use cases:

• IT manager arrives at work and checks on the state of their desktop/laptop fleet.
• They see from a daily check-in report that x% of their fleet has not checked-in (i.e. did not successfully sync w/ the server that is track all of the devices)
• IT manager tries to figure out what happened to x% of their fleet by doing the following:
• looks at a Top Errors report to see what were the top errors in the last 24hr and if any of those might be the reason why
• some part of their fleet hasn’t checked-in
• Looks at a duration from last check-in report to sees that 70% of laptops checked-in in the last 24 hours, 80% of laptops checked-in w/i the last 48 hrs, and 85% of laptops checked-in w/i the last 72 hrs. (i.e. meaning 15% of their fleet hasn’t checked-in in the last 3 days)
• Looks at a state change report over the last 7 days and see a change event that occurred 3 days ago that was applied to the entire fleet.
• Looks at a change event report and saw the change that was made failed on some but not all of the Windows 10 devices in their fleet
• Finds a unique Windows 10 device in the fleet that failed and looks at all known information about that device to try and figure out why

Evidence As part of launching our Desktop Offering we want to provide a visual display for these user types that will help them manage their fleet by viewing status and being able to troubleshoot.

Dependencies

• UX team has to define workflow and visuals
• UI team work has to be prioritized to fit this in

Acceptance Criteria

• Support unique dashboard view for Desktop reports/view only (e.g. separate tab/page for Desktop that is not mixed w/ existing server reports/views)
• Link to available Ohai data
• Need to store more than 24 hours worth of data
• Support .csv & JSON exports for report views

• Type of data for Dashboard view: Priority	Report/view description
  1	Current/known state of desktop/laptop fleet (e.g. breakout by Platform, OS versions, etc…)
  2	State changes over time (e.g. for a given time span, what has change, how much of the change succeeded, how much failed)
  2	Change event report (e.g. shows the success/failure of a specific change event that can be broken out by device/node info such as Platform, OS version, etc…)
  1	Daily device check-ins: Fleet check in, this is the Raw count of the entire fleet
  2	Duration since last check-in: provide a percentage of devices that have checked in versus haven't checked in
  2	Top errors: By "top" we are referring to errors for a given time span. Aggregate all errors that have occurred and show it like a "top ten" report Per 3/16/20 discussion w/ Automate team - for the initial release, Top errors report will aggregate errors from desktops that have checked in at least once in the last 7 days. (i.e. from the time when the report data is pulled/generated) Future: Historical view of errors (i.e. goes back multiple months) for users who want to do analysis or post mortem reviews using that data.
  1	Device details: All data we have on the devices, this would include OHAI data

Assumptions/Constraints

• This effort is to primarily focused for ChefConf 2020, customers using this will not occur until Q4 2020
• At most large Enterprises, the IT team responsible for managing company desktop/laptop equipment is completely separate from the IT operations teams that manage external customer facing servers. (i.e. different leadership and budget centers)
• The types of information that is useful to IT managers of desktops may be significantly different than what is useful to IT operator managing server. As such, it is a better experience for IT managers of desktops to only look at information that is relevant to them (i.e. excludes server views)
• IT managers of desktops may not even be allowed to have access to views of servers in some cases If infra changes are needed, we can align w/ that team for support and get it in their work queue
• Target end of Q3 2020 for customer release of this dashboard and views
• For Infra stuff, automate today stores last known state for each node in one index (powers list view) & historic reports for each run

Out of Scope

• Allowing user to set data ranges
• InSpec data
• Fancy exports (e.g. .pdfs)

Open Questions

• Q & A tracking link: https://docs.google.com/spreadsheets/d/13-9E0sokT1YSqazzWDx3XhM0saYXgoUDnzqlVcHvlHg/edit?usp=sharing

[susanev]

How do we guarantee this user only sees the Desktop Offering Dashboard view?

we can create a new access management role for this

[kmacgugan]

• Need to store more than 24 hours worth of data

This is already true excepting the ohai data, which we only store the latest data for. Will we be needing historical ohai data or just the current ohai data? Ohai data can be very large and managing historical data introduces new technical challenges. We store the rest of the chef-client run reports going back to configurable data retention settings.

[nataliesea]

• Need to store more than 24 hours worth of data

This is already true excepting the ohai data, which we only store the latest data for. Will we be needing historical ohai data or just the current ohai data? Ohai data can be very large and managing historical data introduces new technical challenges. We store the rest of the chef-client run reports going back to configurable data retention settings.

yes, we will need historical Ohai data for certain values. Does that help? We don't need ALL of the data, but some.

[kmacgugan]

Yes, it helps clarify, do we know what those keys/values are? One of the challenges we've had with ohai data is that it is largely dynamic (including the keys! sometimes it uses values as keys!) so it poses a challenge to mapping in ES.

[nataliesea]

We are doing discovery, so we will definitely know before we start implementation! Data mapping should be done during our UX work.

[danielsdeleo]

Product Decision: Top Errors API/UI

The UI mockup shows a "Top Errors" panel. We had a discussion of how this should work over time, in the context of several use-case scenarios and what is the most feasible to implement today.

We agreed that for an initial implementation, we will aggregate the top errors from the node state index, with a hard-coded filter to include only errors from the past 7 days.

In other words, we are counting the errors on a node-wise basis where the most recent Chef Client run for that error ended in failure, and the most recent Chef Client run occurred within the past 7 day time period.

This design does not support trend information or historical analysis use-cases. Work to support those will be scheduled for later.