Iotedge: Deploy when ready

[josiahlaivins]

We have some docker containers that will be doing critical processing. The last thing we want is for a Module to be processing some data, and then reset mid-process due to a new deployment (such as an updated image).

Is there a way to only update a module when the module says it is safe to update?

[CindyXing]

Thanks for the question.

We don't have this capability when deploying/running containers on a single node. One possible workaround is to deploy a new module and use the --volumes-from in the option. This is hacky though.

Can you elaborate more of the scenarios you are trying to achieve? It is useful for us to evaluate the priority when planning.

[josiahlaivins]

For example we have a user/machine drop a csv into a volume. The Module is going to load the csv and begin processing it then output a processed csv. We would like the Module to indicate that it is in the middle of processing that csv, and only be updated once it indicates it is no longer processing anything.

While we could do some form of caching, we really need the module to only update/restart when it is idle because there may be a user on the other end expecting the output.

I am imagining a twin property like update_ready: {true | false}. When the module starts processing, it sets its twin to false, then when idle sets the twin to true. We are currently using the python sdk, and so could use that to toggle the twin.

[kirksw]

We also have a need to control when a module should be updated, as the module is real-time optimizer, so the last thing we want is that the container should be swapped out while it is running. Also we would actually like to implement it, such that the user should choose when the upgrade should happen.

I like @josiahlaivins approach of using flags on the device twin. Because I think that having control on the update is very important when it comes to more complex applications.

[davidzwa]

We have similar needs, currently considering our OTA-process for a time-critical set of processes. Currently we measured a down-time of less than 30 seconds for a fresh sample Edge-module and about 15 seconds for a image-layer-updated edge module, both which can already cause high financial damage. I can imagine that with bigger code-footprint, these numbers will only go higher.
Each process needs to be controlled by our client timing-wise: they need to approve an update and approve down-time on their time-schedule, not the schedule of the edgeAgent. Then renewing the container can be started by the client as well: when they deem it safe

A down-time of <10 sec is very desirable in our scenario.

Therefore being able to control when containers are pulled, as well as when they are refreshed is critical to our application. Knowing how long this takes is also essential.

[davidzwa]

@myagley @CindyXing I would be awesome to get an update on whether we can expect a 'safe-to-restart' policy in future.

[veyalla]

Please file or vote for existing feature request at https://feedback.azure.com/forums/907045-azure-iot-edge