Open RachelElysia opened 1 month ago
Thanks for tracking this @RachelElysia!
(Anyone on our FE team should be capable of the fullstack work to add API filtering and UI changes)
What's your rough estimate on the amount of work for one engineer? (frontend + backend work) 3 points? 5 points?
I think this is a good one to take in the upcoming design sprint so that we can build it if we have capacity next sprint.
I believe I've heard folks at customer-rialto
requesting this. cc @zayhanlon
@noahtalerman fullstack 5?
Hey @RachelElysia heads up that this story didn't make the 3 week drafting => estimation timeline so it's been dropped (deprioritized)
If you think we should consider prioritizing this please bring it back to feature fest. Thanks!
Hey @georgekarrv and @sharon-fdm Not sure which team will be working on this one so I assigned both of you. It's small UI change.
@marko-lisica, NP. we can take it.
So, we have an issue with this as-spec'd.
The vulnerabilities by OS version endpoint platform filtering handled Linuxes as e.g. amzn
and ubuntu
rather than as generic "linux" (and this is how platform is returned as well). This means that filtering by platform=linux
without API modifications will return zero results (platform filtering doesn't support multiple entries, so we can't work around client-side by passing the list of Linux platforms defined in HOST_LINUX_PLATFORMS
in platform.ts
). While we use this endpoint elsewhere, the only platform filtering we do elsewhere is for Windows/macOS (Linux is filtered by a built-in label elsewhere from what I can tell) so we haven't run into this issue head-on.
With that said, we don't actually support OS version vulnerability scanning for platforms other than windows/darwin (and we note that these platforms are not supported in the UI), so if the desired functionality is for checking vulnerabilities, All/Windows/macOS would be sufficient by virtue of us not supporting any other platform at the OS level at this point. Then we can add other OSes to the filter later as we expand OS support, and Linux just won't show up because we check kernel/package versions rather than overall OS version for vulnerability scanning there, and likely won't change this.
@RachelElysia @randy-fleet is this an acceptable scope change (which keeps these changes limited to the frontend), or do we need to do one of the following:
Personally, I think we should add ios, ipados, and chrome now even if it doesn't have vuln scanning.
Going to defer to product/design about how to go about the UI when the current API does not have Linux as an option
Quick estimate for building/testing getting linux
as a pseudo-platform for OS version: 2pt, with 99.99% of the work on the backend (I have "linux" commented on the frontend now). All of the work would be in the hosts datastore file, inside the OSVersions function.
Per design review, we're expanding scope on this to include adding a linux
platform option on the API, which will allow this on the frontend. Bumping estimate to 5 to account for this (incl. docs updates).
Given priority of #20404, putting dev on this on hold until the endpoint for that is done. This should still make it into 4.57.0, but will be closer to the cut.
Goal
Context
Changes
Product
GET /api/v1/fleet/os_versions
already hasplatform
param.Engineering
QA
Risk assessment
Manual testing steps
Testing notes
Confirmation