Delaying refreshes and registration (in particular for pre-seeded classic images)

This is a reprisal of the topic Lazy/fallback serial registration for classic.

We have already implemented naive lazy registration for classic systems without any snaps preinstalled, so that they don’t register with the store until snapd is actively used and snaps installed.

Now though:

  1. snaps are useful and we are going to get more images with pre-seeded snaps
  2. it might be unexpected to get an immediate refresh for for example cloud images that were built to be good to go
  3. some useful/interesting feature will depend on the device being registered
  4. it still feels appropriate to delay registering until snapd is actively engaged with the store

About 1. and 2.:

  • we always planned to have some way to delay refreshes (without changing the overall schedule), some kind of snap delay-refresh command
  • we could implement that functionality and leverage it internally to set up some default delay at first boot for pre-seeded classic images (or some subset of them)

About 4. and 3.:

the original plan was indeed to delay registration until the first store operation on classic, the complexity is that the actual store operations (except download and other auxiliary bits) are invoked synchronously (not inside a Change) very early for something like snap install etc, this was not the case at some point but the new placement is to give quick feedback in case of errors and also avoid creating fully pointless Changes. Possible plans look like:

  • execute key generation (which can be expensive) early in any case but stop there
  • add code to the layer that mediates store and getting device registration bits to trigger the rest of registration on-need (once triggered the usual retry mechanisms should also be activated)
  • the code in the mediation layer would need to wait up to a reasonable timeout for registration to complete or otherwise have the store code try to proceed without device info

One problem here is also how to give good feedback to the user if the reasonable timeout that we should use ends up being long.

A different plan would be to move back talking to the store to be inside changes and dedicated tasks, this is complex, and would need thinking to still preserve the early/immediate errors behavior we enjoy now.

Last updated 7 months ago. Help improve this document in the forum.