Update firmware version

[pintify]

Hi,

We are trying to manage an update of firmware (neither kura, nor packages, but a different firmware) through kura. So far we've taken advantage of the DEPLOY-V2 request and DeploymentService for the installation, but we need to report back the version to the platform.

As of this moment, what we have done is to update the kura properties (specifically kura.firmware.version) so that the birth certificate carries the data without the overhead of creating a new custom request. It works like a charm when you are willing to restart kura and as the field is unused and the concept matches, it fits perfectly our needs. However, restarting kura is not really needed in the firmware upgrade process. To avoid the restart we intend to upgrade SystemService live and resend the birth certificate. We managed to reflect the new version directly to the System properties (still reporting it to properties file, of course) so that the SystemService has the data updated without restart. However we are stuck in this point. First, because we don't know how to force a reactivation of the SystemService. Second, and more important, because we are worried that the pipeline is becoming a bit bizarre. Could you give us some advice on the matter?

Kind regads

[nicolatimeus]

Hi,

I don't think that there are many viable alternatives at the moment, restarting Kura is probably the best one in my opinion.
Deploy v2 should support hooks that are executed at various stages of the deployment process, see service interface [1].
Implementing such a hook should allow to execute custom code at the end of the deployment process, so you could place there some logic that restarts the system service, for example you could disable and re-enable its declarative services component.
One downside of this is that In order for it to work you need to have the hook deployed before the upgrade.
In any case, since there are many Kura components that depend either directly or indirectly on the SystemService, I'm afraid that the effect of restarting it would be very similar to restarting Kura, since all of its dependant services will be reactivated as well, so I don't think that it is worth the effort.

[1] https://github.com/eclipse/kura/blob/develop/kura/org.eclipse.kura.api/src/main/java/org/eclipse/kura/deployment/hook/DeploymentHook.java

[pintify]

Thank you @nicolatimeus, the hook option is good indeed. We are using it already and the logic to update the properties is also in the postDownload method. The hook itself is updated through a standard kura package so it is valid for us to modify it independently if necesary.

What I haven't understood is the "disable and re-enable its declarative serivces component" part. How is it done and why would that restart SystemService?

You may be right about the similarity between restarting the whole Kura or only SystemService, but I think we will try anyway because it's worth the shot if it avoids reloading the WireGraph (in our case is quite complex).

[nicolatimeus]

What I haven't understood is the "disable and re-enable its declarative serivces component" part. How is it done and why would that restart SystemService?

You can get a reference to the ServiceComponentRuntime service, lookup the descriptor of the SystemService and disable and re-enable it.

Before writing any code you should be able to try this out and see what is the effect with the OSGi console, try accessing it with telnet localhost 5002 and run the following commands:

disable org.eclipse.kura.system.SystemService
enable org.eclipse.kura.system.SystemService

We have thought about other possibilities:

• Encode the firmware version using SystemService extended properties, that are recomputed and encoded in the birth certificate before it is published, at the moment this would require you to create a custom SystemService implementation that overrides https://github.com/eclipse/kura/blob/aa0e1d6ec0c293d76afea64c31d3be89467ab875/kura/org.eclipse.kura.api/src/main/java/org/eclipse/kura/system/SystemService.java#L572.

• Remove the kura.firmware.version property and setkura.firmware.version.provider instead, the value kura.firmware.version.provider can be set to the path of an executable script that is executed when the birth is published, the stdout output will be used as kura.firmware.version value.

In both cases you should be able to have the new value published without restarting the SystemService, you will still have to trigger birth republishing from your hook.

[pintify]

Thank you @nicolatimeus for such a detailed answer! We will try the options you propose. We had been thinking of overriding the SystemService for a while now but the provider approach is also very tempting and maybe simpler for our pipeline. We'll let you know what we end up with.