joelguittet / mender-mcu-client

Mender client for MCU, just because it's cool to have it
MIT License
31 stars 4 forks source link

updates: add more control on update flow #53

Closed Piocky closed 1 month ago

Piocky commented 1 month ago

Hi @joelguittet,

As I continue developing my software and use your amazing work as part of it, I just realized that there is currently not much control over the deployment process on client side. If I'm correct, there is only the possibility to set a fixed Update poll interval per device. On the other devices I've developed (which are based on Raspberry Pi), I'm using the 'mender check-update' command line at specific hour instead of the poll interval, as we don't want the device to be updated (and rebooted) if our customer could be using them. I know from Mender documentation that it is possible to add some control over update flow, but it may require a lot of work, and it may not be that critical. But what do you think of having either choice of using the poll interval, or external triggers? Like calling a function (mender_client_work_function, which is currently static) at specific time, or when receiving specific outside commands (HTTP or MQTT)?

I would be happy to help developing this feature, but just wanted to open the discussion first to have your thought :)

joelguittet commented 1 month ago

Hello @Piocky

You're right the default is to have a periodic checking so that the client handle everything for you. When an update is available, it is downloaded and then the restart callback provided when calling mender_client_init is invoked to ask the application shutdown. It is not mandatory to shutdown at this moment, you can also simply raise a flag to inform the user an update is ready to be deployed. In the meantime the client is no more checking for new updates, just waiting a reboot.

As an alternative, the functionality you describe is also available, even if I do not demonstrate it:

Note 1: I'm not testing this feature very often. I have done it once. Later there will be automatic testing in the Github Actions to test various situations, but not for the moment. In case the above scenario is not working, this is because there is a bug. Please open a new issue with logs etc. Note 2: the same feature is also available in addons inventory and configure: period must be set to 0 and then calling mender_inventory_execute and mende_configure_execute. Note 3: I know I have to improve the doc too, so this should be part of it.

Please tell me if this answer your question, and I let you testing.

Joel

PS: I don't think triggering connections based on the clock is a good idea. basically all devices will then connect to the server at the same time and this will cause overload, or maybe low bandwidth when downloading the artefacts. Of course this depends of the number of devices. Having something periodic but not synchronized allows to distribute queries.

joelguittet commented 1 month ago

@Piocky additional information: you can also keep periodic checking and call mender_client_execute function when you want. This is just triggering the update check. Same for addons.

Piocky commented 1 month ago

@joelguittet sorry I didn't spend enough time looking into the code.. I should have seen those functions. Thanks for pointing them to me.

  1. I just tried it, and it works as intended, I will use that instead of periodic check in my case.
  2. Very nice to know, I added them to my workflow too.
  3. Doc can always be improved I guess, it's easier to find out how when you see something is missing :) What about adding that in the help bullet of Kconfig? I can propose a PR if you wish.
  4. Yes indeed, it's just how we implemented it so far, so our devices are automatically updated during the night, at a time chances are very low that a customer is using his devices. But we were thinking of adding more control on that, like let the user choose between automatic update at specific time set by himself, or let him trigger update only when he wants.
joelguittet commented 1 month ago

No problem @Piocky, I m happy this is working for your use case too :-)

For the documentation I will rework it and already started a plan, with contribution guidelines, description of APIs, use cases, etc etc. I will split the readme in several files for that. Not sure about Config, I suppose we can't have all details there, and it's available only for esp IDF and zephyr today, and duplicated...

I'm closing this issue has the as the feature is available and working.

Joel