How does store identify/count unique devices?

I have rolled out a snap to a few devices that are running Debian + snapd. I’ve done that by setting up a reference device with installed snap, and cloning the filesystem image from it onto the other devices. All cloned devices are running fine, checking in with the store, refreshing their snaps, etc.

BUT, in the store metrics all these devices appear to be counted as only one. I’m assuming that that’s because at the time that snapd is installed, it generates (or obtains) a unique device identifier that it presents when checking in with the store. So from the store’s point of view, all cloned devices are actually one and the same.

If that is indeed what happens, is there a way to trigger a reset of this identifier, so that I can get my cloned devices to be recognized as unique? And if the device identification and counting mechanism isn’t what I’m assuming it to be, I’d be keen to know what actually happens under the hood of those metrics.

yes, on first boot snapd goes through a registration process

no, cloned images are not supported, there is no supported way ATM to reset snapd except by removing all state.

The supported approach is to start with an image where snapd is not started and populate /var/lib/snapd/seed/{assertions,snaps,seed.yaml} appropriately including a model assertion. This is what snap prepare-image does for core devices, there is no mode for classic yet, but likely work will happen on that.

Thanks for the clarification @pedronis!

A couple of follow-up questions:

Firstly, is running cloned images likely to lead to other gotchas or problems apart from the incorrect stats? I can certainly live with the incorrect stats, but would like to avoid sleepwalking into a problematic situation where for example snaps stop refreshing due to a device identity conflict. Off the top of your head, am I likely to encounter further issues?

Got it. I’m assuming that removing the state file would also remove (knowledge of) any installed snaps, so that wouldn’t be a great outcome.

Thanks, that makes a lot of sense! Before I waste any time experimenting, I’m assuming that when you say “there is no mode for classic yet”, that means that at present this approach will not work for my setup, i.e. where I have snapd installed on a Debian system?

We may very well start to have duplicate detection in the future. Nearer term we will be rate limiting API requests by device-id (if available, else IP address) so if you had a large number of devices with the same id they could get throttled. Overall I would highly discourage cloning.

my reference about classic mode was for the snap prepare-image tool/tooling itself, what I described as snapd behavior in itself works both for classic systems (with a model with classic: true) and core systems, but for classic systems it needs to be set up manually ATM.

Thanks @pedronis, will give seeding a try in that case.

@noise, thanks for confirming the potential limitations we’d be looking at. It’s just a handful of devices for now and we’re not planning to do cloning at scale, but will try to go about it the right way.

if it’s any help, the ubuntu live cd of 18.04 is a classic environment that includes seeded snaps.