Pre-load configuration profiles into Fleet database prior to silent MDM migration to Fleet

[zayhanlon]

Goal

User story
As a client platform engineer migrating to Fleet,
I want to load my existing expected configuration profiles into the Fleet database prior to silent migration
so that I can migrate to Fleet without removing and reinstalling my configuration profiles. This has side-effects that is noticeable to end users.

Context

• Requestor(s): @zayhanlon
• Product designer: @noahtalerman

Changes

Product

• [ ] UI changes: TODO
• [ ] CLI usage changes: TODO
• [ ] REST API changes: TODO
• [ ] Fleet's agent (fleetd) changes: TODO
• [ ] Permissions changes: TODO
• [ ] Outdated documentation changes: TODO
• [ ] Changes to paid features or tiers: TODO

Engineering

• [ ] 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.

[JoStableford]

Related to a Slack conversation

[noahtalerman]

Customer: For new config profiles in Fleet (already in MicroMDM and applied to device), Fleet is sending a remove profile command. We took the exact contents of profile and added these to Fleet. Note that these are unsigned profiles (signed before adding to Micro) because Fleet is doing the signing.

Hey @zayhanlon, after discussion w/ @roperzh, we think there might be some confusion. We (Fleet) couldn’t replicate the above situation reported by the customer.

The expected behavior is that when a config profile is added to Fleet, Fleet sends an InstallProfile command. What happens next? If a host already has a profile w/ a matching PayloadIdentifier, the host's profile will be replaced by the one added to Fleet.

The plan is to bring this info to the customer next week and ask them to test this.

If replacing the profiles causes any side-effects (ex. popups visible to the end user), then we can pre-load profiles into the Fleet database so that Fleet doesn't send the InstallProfile command.

Closing this issue for now assuming there will be no side-effects. Let's reopen if we learn that we're wrong.

cc @dherder @zwass

[fleet-release]

Silent migration, Config profiles intact, no fuss. Fleet's ease, a delight.

[zwass]

IIUC the key here is that the config profiles need to be preloaded and their contents need to be an exact match to the existing profiles on the device?

[noahtalerman]

the key here is that the config profiles need to be preloaded and their contents need to be an exact match to the existing profiles on the device?

@zwass not quite. If we learn that Fleet replacing a profile causes any side effects (ex. popups visible to the end user), we think we'll need to preload the profile into the Fleet DB with a fabricated timestamp.

Fleet uses the timestamp to know whether to send an InstallProfile command. The exact contents don't matter.

@roperzh please correct me if I'm wrong!