Polite Deployments

General
1

I’m a little confused about polite deployments. Could someone clear it up?

I’m hoping for a feature that will only allow OS or Firmware upgrades during times I allow, but it seems that the feature does not do exactly that.

The docs (https://electricimp.com/docs/api/server/onshutdown/) seem hastly written at best so I’m unsure what to expect. Does “Note ‘New Squirrel’ restart requests are not yet supported so your code will note receive this reason code.” mean that you intend to add this feature in the future? What does “New Squirrel is available” mean? Are you talking about squirrel firmware, language updates, … something else?

Is there any way to test functionality around “SHUTDOWN_NEWFIRMWARE” or do I just hope that my code is correct?

What might cause a “SHUTDOWN_OTHER” event? When I ask the device to restart, my onshutdown handler is not called. What else will cause this to happen?

Given the state of the documentation, it’s not clear to me that the feature has been thought out and finished. Should I be worried about building this into production code?

2

What aspect of the documentation is concerning? It seems pretty straightforward IMO, though it’s obviously written from the point of view of the device, because the server support didn’t exist at the time it was implemented (release 30).

As polite OS deployments are live right now, there’s more detail on that flow here: https://electricimp.com/docs/resources/politedeployment/

At this time, to test this you need to ask us and we can queue devices for different firmware revisions; the onshutdown() handler is called when a device reconnects to the server and the server has a new OS version for it - eg on a wake from sleep, or a disconnect caused by internet weather. A cold power cycle, or build & run when a new OS update is pending, will always cause the update to be accepted.

Polite squirrel deploys are in development (it’s a server-side feature) and will work in much the same way. More news on that when it rolls out in the near future. You’ll only see the handler being called there when doing a production deploy - build & run in the IDE is a big hammer and forces the squirrel update.

In either case, we can force updates if needed. Tools will be provided for commercial customers to force updates if required (eg if the vendor decides the update is more important than whatever the device is doing).

Currently SHUTDOWN_OTHER is not used.

3

Interesting.

Right now, with the following code, I should see information in the log on an OS update, but not a new build deployed, correct? When I run a deploy now, I see neither of these server.log() statements.

server.onshutdown(onShutdown.bindenv(this));
function onShutdown(shutdownReasonCode) { if(enableFirmwareUpdates) { server.log("Restarting on request (reason code: " + shutdownReasonCode + ")"); agent.send("status",{event="restart",code=shutdownReasonCode}) 
	    server.restart()
	} else {
	    server.log("Ignoring restart request (reason code: " + shutdownReasonCode + ")");			
	    agent.send("status",{event="restart-ignored",code=shutdownReasonCode})
	}
}

OS: Device firmware version: e34f138 - release-34.11 - Fri Nov 4 12:19:40 2016 - production

4

The documentation says that ‘New Squirrel’ restart requests are not yet supported. I guess that means that the handler is not called for a deploy. There is a OS deploy in a few hours. Maybe that will trigger something.

5

Correct. As I said only the OS update handler will be triggered and then ONLY on a reconnect.

If you press build&run, or the device is power cycled when the OS update is pending, then the upgrade is just accepted and your handler isn’t called (because your code isn’t running at that point, aside from anything else).