Allow CloudConfigurationHandler to return RESPONSE_CODE_OK *after* the configuration has been effectively applied

[reda-alaoui]

Is your feature request related to a problem? Please describe.

Using Kapua Rest API, I am updating Kura component configurations. Kapua returns an HTTP success response before the configuration is effectivly applied in Kura. This is problematic when your configuration change must be effective before a dependent subsequent action.

I think it is caused by Kura CloudConfigurationHandler behaviour:

kura/kura/org.eclipse.kura.core.configuration/src/main/java/org/eclipse/kura/core/configuration/CloudConfigurationHandler.java

Lines 373 to 376 in 48f242c

	this.executor.schedule(new UpdateConfigurationsCallable(pid, xmlConfigs, this.configurationService), 1000,
	TimeUnit.MILLISECONDS);
	return new KuraResponsePayload(KuraResponsePayload.RESPONSE_CODE_OK);

The configuration update is asynchronously applied. The success response is probably sent before the configuration update process ends.

Describe the solution you'd like

I want Kura to send RESPONSE_CODE_OK after the configuration has really been applied.

Describe alternatives you've considered

My current workaround is to poll the configuration via Kapua REST API until I see my change.

[mattdibi]

Hi there @reda-alaoui,

thanks for reaching out!

Unfortunately your request is not feasible currently.

Our Rest APIs interact with what we call the ConfigurationService which is responsible for notifying each and every underlying component of the configuration change e providing the configuration. All of this is asynchronous in nature and quite hard (or downright impossible) to know when each subsystem completed the update.

We are aware of the current limitation (which also reflects on error reporting) and plan to work on it in the near future.

May I ask you what's your use case? Why do you need to know when the configuration was applied? Knowing that we might be able to propose other workarounds.

[reda-alaoui]

Hi @mattdibi ,

My use case is some automaton that performs kura configuration changes expected to lead to the activation of a RequestHandler down the road. The automaton tries to send requests to the new handler just after the configuration change.

[mattdibi]

Hi @mattdibi ,

My use case is some automaton that performs kura configuration changes expected to lead to the activation of a RequestHandler down the road. The automaton tries to send requests to the new handler just after the configuration change.

I don't have the complete picture therefore take my suggestion with a grain of salt...

The fact that the RequestHandler starts responding should be the condition for which you know the configuration has taken effect, shouldn't it? I would probably poll that handler instead of the configuration via Kapua REST API. But, again, I don't have a complete picture.

If the above is not possible I would say that your solution is the best we can achieve at the moment.