Hey fleet ! I am about to switch over to gitops managed fleet and I have a couple of clarifyinf questions just before I do (don't want to break anything) - I'll put them in the 🧵!

• Agent Options ◦ I'm not sure without testing but the intent is that gitops is declarative so it should overwrite what is in the UI, even if you set the value in gitops as blank (indicating you want what is in the UI to be deleted). If you discover differently, please open a bug so we can track it. I've found a few pockets of this with webhooks recently that have since been addressed. • Policy and Software ◦ Curious why you want to manage via the UI. You can always set secrets in your repo so URLs and other sensitive data is not exposed. See this as an example: https://github.com/fleetdm/fleet/blob/07486aef30bfad2e0208e750d457168a07fc9e4b/it-and-security/teams/workstations.yml#L14. Otherwise, gitops is supposed to be declarative so it will overwrite or change anything in the UI that isn't defined in your yaml. • RBAC ◦ No. Any of the admin/user settings can't be managed via GitOps today. • --dry-run output ◦ The wording could be better but this is just saying its going to create the 1 team. Even though its not a new team, its highlighting how many teams are going to be created. There is a flag to prevent teams from being deleted if needed.

Thanks for this: • Agent Options ◦ To clarify im not setting an option as blank, I am just not adding in the other fields that show on

org_settings

when you pull the config. I am only using the "default" examples from fleet repos. ◦ Ideally I don't want to test this in live, so I may wait until there is a clear answer or docs on what a migration to gitlops looks like. Great if you're doing this from scratch. • Policy and Software ◦ Tested, it overwrites and even deletes the software that was uploaded via teh UI ◦ Reasons: We don't want to open up access to our package store Nexus, as Fleet is internet accessible (so the hosts can communicate). ◦ This is specifically or private packages. e.g ones protected by logging into a platform. In my case, CrowdStrike Falcon. ◦ Therefore to avoid having to create a bucket to put software in, for that to just go directly to the software-installers bucket makes no sense. ◦ Given its declarative, it looks like this is a blocker to migrating to GitOps, for us. ◦ I'll raise an issue as a Feature Request - Can we not just use the current S3 bucket for software installs and point the yaml to the S3 location? This seems way more lean and streamlined. You can even still use the UI to put the package into the bucket. • --dry-run ourput ◦ So it looks like its not going to create a team if it already exists, so for sure the wording here needs updating.