Open dherder opened 1 month ago
@dherder heads up, I updated this issue to use our standard user story template. I moved your original issue description below for safekeeping.
As an IT admin that has heavily invested configuration pipelines with existing OS specific package managers like munki, homebrew, chocolatey, apt, and yum, I would like to continue to leverage those package managers to deploy and manage software installation. I would like to use Fleet as the central management interface to the OS specific package manager so that there is a single experience to deploy a package across my fleet of devices.
As a part of this integration, I should be able to define a desired state of software packages on devices. This might include capabilities to install, update, remove, or version pin packages in a pre-defined recipe for that package.
The problem os managing 3rd party package managers is compounded by the distinctly different approaches to package management across different operating systems. Take the case of managing homebrew for macOS. In this situation, an organization may take one of the following typical approaches:
The pain with all 3 approaches above surrounds the lack of control of package state. The IT admin will have to rely on the end user to run 'brew update' to be able to get the latest packages.
Additionally, homebrew is not going away. So, even though Fleet has a built-in capability to manage (deploy + update) its own "Fleet delivered" software packages in a gitops friendly way, it will also need to be able to manage the homebrew, apt, yum, winget OS specific package managers without having to create endless scripts to be able to interact with these package management solutions.
This might include integration with config management tools like Chef where we build a Fleet module for Chef to orchestrate cookbook generation.
Alternatively, Fleet could build its own recipe generation engine via osquery and leverage the existing policy feature to continually enforce those policies. Related to https://github.com/fleetdm/fleet/issues/17129
Could break out more user stories: 1 for apt (Linux)
@noahtalerman can i get a status update on this one after the air guitar or if the air guitar was completed? @Patagonia121 FYI
Hey @zayhanlon will do!
This air guitar is still in progress. @dherder and I met w/ prospect-numa
to get their feedback on the initial wireframes (see Figma here).
What's left? Plan is to update those wireframes and get another round of feedback from the prospect.
As of now, we don't plan on moving forward w/ the formal drafting => engineering process until we get an order form from the prospect.
That said, I see that customer-reedtimmer
was added. Maybe we get their feedback on the next recurring call?
Wonderful! For sure - they would love to speak with you about it
@Patagonia121 Can you add to next week's customer-reedtimmer agenda and include Noah?
I can do that, except our calls are every two weeks @zayhanlon. Either way, I'll get it on the agenda for the next one and make sure Noah is invited.
Bringing this air guitar to the next design sprint. Adding it to feature fest so folks are aware of what we're prioritizing.
Goal
Context
Changes
Product
Engineering
QA
Risk assessment
Manual testing steps
Testing notes
Confirmation