search

fleetdm / fleet

Open-source platform for IT, security, and infrastructure teams. (Linux, macOS, Chrome, Windows, cloud, data center)
https://fleetdm.com
Other
3.11k stars 428 forks source link

Allow software installers to be excluded from GitOps workflow #20907

Open ddribeiro opened 3 months ago

ddribeiro commented 3 months ago

Problem

customer-easterwood wants to use Fleet's GitOps workflow to take advantage of configuration as code workflows and change management.

However, they also have help desk employees in their organization that use Fleet only to upload software installers. The help desk team prefers to use the UI for this action.

This is an issue because the next time the GitOps workflow is run, the state of their Fleet server is reset to whatever is defined in the GitOps yaml files. This means the software installers uploaded via UI by the help desk team are removed because GitOps always beats out the UI.

The customer is looking for a way to continue using GitOps for everything but uploading software installers.

What have you tried?

The customer has tried to use Fleet's GitOps workflow to manage their Fleet instance and allowed their help desk staff to upload software installers to Fleet via the UI. The software installers uploaded through the UI get overwritten when the GitOps workflow runs.

Potential solutions

Solution 1: Modify GitOps workflow to allow exclusions for certain objects/settings if they are not defined in yaml.

In this solution, the GitOps system would be changed from the way it works today to not modify anything on the Fleet server if it isn't explicitly defined in the yaml file

For example: If a GitOps yaml file does not include a software object, then GitOps will not touch the state of uploaded software. If the customer wanted to reset state of uploaded software when GitOps runs, they would include an empty software object.

Solution 2: Export current state of Fleet in yaml format

In this solution, the "current state" yaml format could be exported from fleetctl or the UI and can be directly plugged into the GitOps workflow.

This would allow a GitOps user to take a snapshot of the current state of their Fleet server to capture any changes added through the UI.

This might be desirable for customers who want to be selective with when they overwrite changes made via the UI with GitOps. It could also lower the barrier for entry for Fleet UI users who want to migrate to a GitOps workflow.

What is the expected workflow as a result of your proposal?

Generally speaking, the expected workflow would be that GitOps could be used with a way to prevent UI changes from being overwritten. This wouldn't apply to all situations, as there will still be customers that **do** want UI changes overwritten by GitOps. #### Solution 1 The customer would build their yaml files and exclude the `software` object to tell Fleet GitOps not to overwrite it when `gitops.sh` is run. The help desk staff would be able to upload software installers via the UI without them being overwritten by GitOps. #### Solution 2 The customer would build a workflow to export the current state of their Fleet server. They would then use these yaml files as the source for their existing GitOps workflow. This would allow the customer to capture changes made to Fleet via the UI so those changes would not be reverted/overwritten when `gitops.sh` is run.
noahtalerman commented 3 months ago

Thanks @ddribeiro!

I think something like solution 2 is where we want to head. I chatted with prospect-numa about a similar feature in which the UI would output YAML that the less GitOps experienced users could then submit as a PR.

Do you think this workflow would work for customer-easterwood? Or is help desk never going to be in GitHub.

noahtalerman commented 3 months ago

@ddribeiro also, I'm wondering if something similar to solution 1 for just could be a quick win.

The customer would build their yaml files and exclude the software object to tell Fleet GitOps not to overwrite it when gitops.sh is run.

@getvictor are there any tweaks we could make to just gitops.sh so that GitOps ignores a missing or empty software key? (doesn't overwrite software added in the UI)

Or would this require code code changes to fleetctl

getvictor commented 3 months ago

@getvictor are there any tweaks we could make to just gitops.sh so that GitOps ignores a missing or empty software key? (doesn't overwrite software added in the UI)

Or would this require code code changes to fleetctl

This would require code changes to fleetctl.

noahtalerman commented 3 months ago

Jason: Working to adopt GitOps but they're not there yet.

Dale: They aren't investing in GitOps because they wouldn't be able to use software features.

Noah: I don't think they're the only one who wants UI some things + GitOps for other things.

Dave: Other customers will have a hard time migrating from GitOps.

Noah: Good to think about these problems at the same time.

JD: Solution 2 would be best at Fleet

spokanemac commented 3 months ago

Related: https://github.com/fleetdm/fleet/issues/12584

marko-lisica commented 2 months ago

Hey @ddribeiro, heads up, this story wasn't completed in the last design sprint. It won't hit 6 week drafting to release timeline. We added it back to feature fest.