Scope software install to hosts by labels

[marko-lisica]

Goal

User story
As an IT admin,
I want to install the Fleet-maintained apps, custom packages, and App Store apps (during the first boot or later) only on macOS, Windows, and Linux hosts that are a member of the specific label
so that I can scope software install more granularly (e.g. by department, role, hardware, etc.).

Key result

Fleet users can automatically install any software in Fleet w/o writing policies

Original requests

• 21825

Context

• Product designer: @marko-lisica

Changes

Product

• [ ] UI changes: Figma link
• [ ] CLI (fleetctl) usage changes: No changes.
• [ ] YAML changes: #24085
• [ ] REST API changes: #24085
• [ ] Fleet's agent (fleetd) changes: No changes.
• [ ] Activity changes: TODO
• [ ] Permissions changes: No changes. Permissions covered by "Add, edit, and delete software" row in the permissions guide.
• [ ] Changes to paid features or tiers: Fleet Premium.
• [ ] Other reference documentation changes: No changes.
• [ ] Other changes:
  • If the host isn’t part of the scope that’s set on the software title level (isn’t member of included labels or is member of excluded labels):
  • The software title can't be installed manually (API returns error)
  • Won't be installed automatically as part of policy automation if the host fails the policy.
• [ ] Once shipped, requester has been notified

Engineering

• [ ] Feature guide changes: TODO
• [ ] Database schema migrations: TODO
• [ ] Load testing: TODO

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

QA

Risk assessment

• Requires load testing: TODO
• Risk level: Low / High TODO
• Risk description: TODO

Manual testing steps

1. Step 1
2. Step 2
3. Step 3

Testing notes

Confirmation

1. [ ] Engineer (@____): Added comment to user story confirming successful completion of QA.
2. [ ] QA (@____): Added comment to user story confirming successful completion of QA.

[noahtalerman]

Hey @marko-lisica! This user story is looking good. I pulled it into ready and assigned you.

A couple things to think about as we draft the user story...

• At the user story level, I think we want to use specific language for "software" like "Fleet-maintained apps," "custom packages," and "App Store apps" in the title and user story. This way, the product/engineering team can understand the scope of the feature. Are we going to design/build scoping for all apps in this pass? I'm thinking we start by designing what it would look like to scope all and then we can decide to cut down (if needed).
  • It makes sense to use the word "software" or "apps" at the feature request level. As a user/customer, an app is an app. I expect to be able to do the same scoping whether it's a package.
• Also, when designs are ready for specs, I also think we want to use specific language for platforms (macOS, Windows, Linux). Are we going to design/build a solution for all platforms?

[valentinpezon-primo]

Hi @noahtalerman @marko-lisica

Since #22156 issue is going to be tacked first (as per @zayhanlon said) , it it possible for this current (#22813) issue to also wotk with "any" label ?

Basically, we would like to have the ability to be able to scope software install by label, by also using "any" and not only "include all"

Something like this :

Based on the os settings view:

[marko-lisica]

Hi @valentinpezon-primo, thanks for the feedback.

I think that's what we are aiming for (Include any - software will only be installed on hosts that are members of any of the selected labels) in order to support one of the main use cases: scope software by department or role.

cc @noahtalerman

[noahtalerman]

Hey @zayhanlon and @pintomi1989 heads up that this didn't make the 3 week drafting timeline. The plan is to continue working on it and prioritize it in the next design sprint. It contributes to the "Mission critical app management" Q4 objective.

[allenhouchins]

prospect-leiden brought up a scenario today that provides another good example of why scoping software by labels is important. They have a mix of Linux devices and want to make sure their end users only see the relevant installer in self-service for their device (rpm vs deb).

In general, this would also help with scoping arm64 vs amd64.