DRAFT - for discussion - DRAFT

We have a range of different ways the controller can tell from the info messages that a create/modify/operation is still in progress:

 - a new object was created, and we have not yet seen an info message from EVE for that object

 - an object was modified, e.g., an app instance stopped or started, and the ZSwState has not yet changed in the INFO message. (Note that the stop will immediately result in a HALTING state to indicate the change has been initiated by EVE). This is different for different changes

 - A restart or purge operation was issued against an app instance, and the ZSwState has not yet changed to RESTARTING and PURGING, respectively

 - A device reboot command was issued, and (once the reboot has completed) the rebootConfigCounter has not yet been incremented to match the counter in the EdgeDevConfig

Note that the semantics are different - some like the device reboot we don't get feedback until the operation is complete, whereas others we get feedback when it is initiated.

However, some operations do not have any indication. Notably, when the controller modifies the ACLs for an app instance, we can not tell whether EVE has updated the ACLs.

However, if the ACL modification results in a change in the version field in the UUIDandVersion for the app instance, then this will be echoed when EVE receives the modification (which is before the ACL modifications get applied).

We should document this and come up with a more common scheme for this.

EVE API semantics

One aspect is whether EVE has received the new configuration (and due to network outages that might take a while). But if all we care about is checking whether EVE has received the latest we can either have the UI get information from the controller about the last ConfigRequest it serviced, and we can also have EVE report the hash of the most recently received EdgeDevConfig in the device info message.

But if we also want to know that EVE has acted on things we get into more specific details. As stated above, if EVE receives config for a new object, it will start reporting that object in info messages. And if it performs some “significant” change to an object EVE might report a different state (to date this is mostly for content trees, volumes, and app instances, but we are adding some states for the device itself and the network instance). But as stated above, “minor” changes like applying an ACL are not reported. The reception of the ACL change could be inferred from the hash of the EdgeDevConfig, but it might take a while for EVE to apply that change. And we don’t necessarily want to report the whole list of applied ACLs in the info messages since they can be large.

UI/UX considerations

If the user has issued an EVE reboot command, once EVE sees that (and with the new device states), it will appear in the event log as a state transition to REBOOTING (or SHUTTING DOWN). But until EVE sees this there is no indication that a reboot command is pending. Should we add some way to indicate this to the user? And if so, should that keep showing it as in progress until EVE has rebooted?

The above is just an example; all operations except creation of new objects could potentially benefit from a notion that the operation has started (been sent to the controller, been received by the edge-node, been applied). Some operations like deploying a new content tree or app instance might have a more detailed state progression, but we lack some visibility for the modifications and operations.

Considerations

Look at how cloud APIs such as AWS Device Shadow service documents - AWS IoT Core handle this