Show download URL for Fleet-maintained apps

[marko-lisica]

Goal

User story
As an IT admin at Fleet,
I want to see the download URL Fleet-maintained apps
so that I can verify that Fleet is downloading the software from a trusted third-party vendor.

Key result

DOGFOOD: 20 celebrity apps for macOS and Windows are managed/patched in dogfood using Fleet-maintained apps

Original requests

#22616

Context

• Product designer: @marko-lisica

Changes

Product

• UI changes: Figma link
• CLI (fleetctl) usage changes: No changes.
• YAML changes: No changes.
• REST API changes: [API changes] Show download URL for Fleet-maintained apps #24583
• Fleet's agent (fleetd) changes: No changes.
• Activity changes: No changes.
• Permissions changes: No changes.
• Changes to paid features or tiers: Available in Fleet Premium.
• Other reference documentation changes: No changes.
• Once shipped, requester has been notified

Engineering

• Feature guide changes: https://fleetdm.com/guides/install-fleet-maintained-apps-on-macos-hosts
• Database schema migrations: store download URL
• Load testing: No

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

QA

Risk assessment

• Requires load testing: No
• Risk level: Low

Manual testing steps

• On the software details page, a new "Show details" link appears to the far right of the software title name, OS, version panel
• Clicking "Show details" opens modal that shows Name, Platform, Version, and URL
• Hovering on URL shows tooltip with
• Software with very long names, versions, or URLs do not have overflow issues within the model
• URL can be copied from the modal
• API GET /api/v1/fleet/software/fleet_maintained_apps/:id includes url, filename, and version fields

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, I just watched your Loom here.

My thoughts:

• Adding the URL to the API makes sense! I think let's take the wireframe-first approach. Can you please see what the URL would look like in the UI? That will help inform the API changes.
• Your script is great! We should start dogfooding that ASAP. I see what you're saying re inline scripts providing a superior UX. Can we make your script work without inline scripts at first? I think this would make this iteration smaller.

[noahtalerman]

@marko-lisica, I left some more feedback in a Loom here.

[marko-lisica]

Hey @allenhouchins, @noahtalerman mentioned that you're working on Fleet's best practice software management. With this story, we're trying to provide a way to manage Fleet-maintained apps via GitOps.

I recorded a quick video to walk you through the UI/API changes and script (a utility to create YAML files from Fleet-maintained apps) and get feedback on it.

Loom video: https://www.loom.com/share/9b84ed653d254c50a5bada15fa3edbcd

@kennyb-222, I hope you’re doing well! If you have a moment, could you please take a look at this and share your feedback? Your insights would be really helpful. Thanks so much!

[allenhouchins]

@marko-lisica It's looking good. As long as there is a way to discover the Fleet-maintained app download URL programmatically, without first having to upload it in the UI, this will be great -- which I believe is what you are showing with that script. I've got some thoughts that aren't in scope of this issue -- like being able to scope automatic deployment of software to labels instead of or in addition to teams -- but this is otherwise looking good.

Not a blocker in any way but one thing that seems to be missing that I think would improve the experience and scale of the YAML files is some kind of indication that this is going to show up as a Fleet-maintained app instead of a custom app. Since custom apps are always going to have a third-party download URL, it may be confusing where to see the results of GitOps in the UI. I might also have multiple versions of the same app I need to support in an environment -- one for Fleet-maintained, one for VPP, and/or one custom.

One concern I have is making sure we understand server spec requirements. If the YAML files are going to behave the same way they do today for custom apps, where the server downloads the software directly (twice in the case of dry runs), then I'm concerned it will be easy to crash the server as soon as multiple software titles are added. See this for an example: #20595

[marko-lisica]

@allenhouchins Thanks for the feedback!

I've got some thoughts that aren't in scope of this issue -- like being able to scope automatic deployment of software to labels instead of or in addition to teams -- but this is otherwise looking good.

We're currently designing this story: #22813

Not a blocker in any way but one thing that seems to be missing that I think would improve the experience and scale of the YAML files is some kind of indication that this is going to show up as a Fleet-maintained app instead of a custom app. Since custom apps are always going to have a third-party download URL, it may be confusing where to see the results of GitOps in the UI.

Not sure if I fully understand this, but would be helpful if we make as best practice to have lib/software/fleet-maintained folder for Fleet-maintined apps?

I might also have multiple versions of the same app I need to support in an environment -- one for Fleet-maintained, one for VPP, and/or one custom.

Currently, Fleet doesn't support this. Only one type can be added (either custom, Fleet-maintained or VPP) to the team. Users can add Slack app only once. To add a new version user can remove the existing package and then add new one (custom, Fleet-maintained or VPP).

One concern I have is making sure we understand server spec requirements. If the YAML files are going to behave the same way they do today for custom apps, where the server downloads the software directly (twice in the case of dry runs), then I'm concerned it will be easy to crash the server as soon as multiple software titles are added. See this for an example: #20595

Fleet-maintained apps work the same way as custom packages. Fleet server downloads package from URL and then hosts download from Fleet once install is queued. I see that #20595 is ready for release. I think we should try to dogfood first and see if it works.

[allenhouchins]

@marko-lisica - Thanks for the detailed response!

One other thing that just came to mind, since a lot of our Fleet-maintained apps are dmg and zip files, this means we can't gitops these software titles until this is implemented, right? #21920

In 4.59:

Couldn't edit software. File type not supported. The file should be .pkg, .msi, .exe, .deb or .rpm.

[marko-lisica]

@allenhouchins You're right. I forgot about .dmg and .zip files. With this change we would be only able to add .pkg files.

We have an issue to support upload of .dmg and .zip files: #21920

[georgekarrv]

Summary of effort.
Backend add url to get FMA details response.
Frontend add modal with details including url.

@ghernandez345 @gillespi314 can you just drop an async estimate in here? Then we can skip estimation today

[georgekarrv]

Hey team! Please add your planning poker estimate with Zenhub @ghernandez345 @gillespi314

[lukeheath]

@mostlikelee Moving back to "Ready to spec" for TODOs.

[noahtalerman]

FYI @marko-lisica @eugkuo, I updated the title and user story to clarify the problem we're addressing in this story: IT admins want to know that Fleet is getting the apps from the respective vendor.

Managing Fleet-maintained apps via GitOps is now covered in a separate story here: #24469

I also updated "Download URL" to just "URL" in the UI. Less copy:

[noahtalerman]

@mostlikelee reminder that this one is ready to spec. Can you please take on the "TODOs" in "Engineering" section so we can estimate this one?