modify semantics of bootme attribute to support delayed reboot

[James Hunt]

system-image currently supports a 'bootme' option that may be present in the JSON and instructs Touch to reboot _after it has finished downloading the current file_.

However, Core has a slightly different requirement. It attempts to minimise reboots, but when certain packages (like the kernel) have been updated, a reboot will be required. Crucially though, this reboot should not occur until the the system image has been fully downloaded *and* fully unpacked.

After a discussion with barry+mvo, we think the best approach is to modify the bootme flag to be able to specify a 'deferred' value meaning "reboot at end of download+unpack".

[Barry Warsaw (barry)]

James, let me know if this is still a priority. For now, I'm bumping down the priority and removing it from the 3.0 milestone, but I'm happy to add it back if needed.

[James Hunt (jamesodhunt)]

Hi Barry,

I think you're right to lower the priority for now; this bug was raised when we only had a single rootfs but now (well, for now) we assume dual rootfs's which will require a reboot to toggle between.

It would certainly be useful for the client to be able to query the bootme flag (via a "target_bootme" option in .Information() maybe?) so that snappy can store that setting locally after s-i has finished downloading and installing the latest image but be able to continue warning the admin that a reboot is required as flagged by s-i.

So if the current use-case for boot me is:

a) reboot required since a new kernel/initrd is included in the image (already handled by bootme).

... I wonder too if we want to enrich the semantics of bootme to also support:

b) reboot required since the new image contains important security fixes.

Although (b) will require some thought as to how/when we flag that scenario across an entire s-i (it almost implies a way to categorise changelog entries into "bug", "feature", "security" or similar to allow us to automatically generate the correct bootme flag value?)

[Barry Warsaw (barry)]

On Feb 10, 2015, at 09:25 AM, James Hunt wrote:

>It would certainly be useful for the client to be able to query the
>bootme flag (via a "target_bootme" option in .Information() maybe?) so
>that snappy can store that setting locally after s-i has finished
>downloading and installing the latest image but be able to continue
>warning the admin that a reboot is required as flagged by s-i.

One thing I find interesting about this is that there may be more information
on the target image spec (from the index.json file) that you could be
interested in. What if we found a way to make all the scalar bits of
information available in the .Information() dictionary (i.e. omit any nested
values such as the `files` key)?

>So if the current use-case for boot me is:
>
>a) reboot required since a new kernel/initrd is included in the image
>(already handled by bootme).
>
>... I wonder too if we want to enrich the semantics of bootme to also support:
>
>b) reboot required since the new image contains important security fixes.
>
>Although (b) will require some thought as to how/when we flag that scenario
>across an entire s-i (it almost implies a way to categorise changelog entries
>into "bug", "feature", "security" or similar to allow us to automatically
>generate the correct bootme flag value?)

I need to check, or ask stgraber, but I think there's a way in the server to
manually specify bootme on other conditions. You're right that we probably
should auto-detect that somehow.