Enable function to take scheduling of deployments poll outside of library.

[havrak]

I would very much like to be able to take care of scheduling deployment polls on my own. However as things stand all methods are locked behind mender-client.c. Not to mention if I didn't missed something polls one cannot disable periodic polling at all.

I have no problem writing it a pull request myself - something like where 0 value would denote disabled polling and declarations of these functions (poll for deployment, reauthorize) would be moved to header file for client. Just wanted to confirm this doesn't clash with your vision for the project.

Thank you in advance

[joelguittet]

Hello @havrak

Not a bad idea! I m happy to read this library can be useful and really want to drive development according to what real projects need.

Let me check and schedule something on this topic, that may lead to important modifications, architecture etc. I will inform of the progress here.

mender-rtos part of the platform will probably need exclusion. Probably also need to have a single poll function for the mender client instead of initialization/authentication/updates so a state machine is probably required. Need to think about the add-ons too.

All of this probably linked with the bare metal version I would like too :-) (is it your use case ?)

Joel

[havrak]

First of all I would like to thank you for even writing this library. I've just started experimenting with Mender and this library and that fact it was for esp-idf was a great help.

Making rtos part a seperate scheduler, maybe toggleable with Kconfig could be the best solution, for the time being. I probably have (Uni is starting again) time to write push request with these changes. In the long run maybe making/using completely separate, mender agnostic, scheduler would be better. Though than some thread safety logic would then have to be inside mender library, preferable toggleable again. Schedulers are often present in embedded projects anyway so this could prevent some code repetition, not to mention keeping stuff centralized and supervices.

When it comes to different poll functions I don't really see a problem with them being separated as the separation will take place on one or a another layer. And deep down they will necessarily be different functions. So it would just be added logic to pick action with some enum and than immediately evaluate it and choose routine. Maybe less clutter on library user side.

Personally I frequently need to have at least regular mode and maintenance mode on my projects. Vision is that the device should regularly poll with long interval for new versions or poll only in night according to cron expressions (which my personal scheduler supports). However if the maintenance mode is activate (downlink, physical button) I want to speed up polling so maintainer, who could even be on side, doesn't have to wait hours to see result. Still all projects in close future will run on LoRaWAN where polling will only be done in maintenance mode when someone physically brings LTE modem to them.

[joelguittet]

Thanks for sharing all of this ! I m happy to see this library is helping people.

About the scheduler, I don't plan to remove it, because the initial design is "initialize me and then I take care of everything for you, I will just report callbacks when I need something". I have particularly implemented something that permit multiple task to share a single thread, thus reducing the ram consumption instead of having multiple stacks. And of course I ensure this is working on the devices.

But has discussed above this does not prevent (using Kconfig of course) to permit using your own scheduler and take care of all the related stuff, such as priorities, stack size, etc.

[joelguittet]

hello @havrak I have merged new API in the library to allow disabling the periodic execution and triggering the works from the user application. Please check at https://github.com/joelguittet/mender-mcu-client/pull/26 and tell me if this is suitable for you. The philosophy was instead of removing the rtos scheduler, keeping it to ensure kernel related issues that the library aims to solve (priorities, stack size required for the mender client). Moreover, this also permits to keep periodic execution and to ask for additional triggered executions based on application events in parallel. The implementation garantes there will be no conflict on shared resources etc. For example if the inventory or the configuration must be refreshed based on the user interactions at some time. Joel

[havrak]

From brief look at the code everything I needed, and more, was implemented. Way RTOS is now handled is perfect for me - it's user controllable, takes care of all synchronization issues and given how long http requests take added complexity from it is negligible. I have to admit that making it removable wouldn't be a good choice after all.

Just an idea: Wouldn't it be better to have platform agnostic Kconfig that will be sourced with source(), or rsource (in case of esp-idf)?

Otherwise the issue can be closed, I think. Thank you for cooperation. Krystof

[joelguittet]

Thanks for your message, I will close in this case. About the Kconfig, probably yes. I have not checked the topic for the moment.