Implement a reconciler to enable guaranteed delivery semantics for operators.

A prototype system I’m working with has a controller implemented using the java client and one using this javascript client.

Both serve a similar purpose, they watch some configmaps and apply changes to some service in response to the events they receive.

In the java case there is the concept of a reconciler and in the javascript the controller is based on the informer example.

The main interesting difference is that the java case has a clear way to handle errors. Specifically errors that occur when using the event information within the controller to update some other service. If an error occurs with the java client then the reconcile function changes its return value. The system will then call it again later to have another go at handling the same events.

In the javascript case we can’t see any support for handling this particular type of error. Is it possible? Or is that not supported? (Searching across kubernetes-client this type of support was only obvious with the java client.)

Some more detail:

If there was code like this how would an error be handled such that the system would retry this add event later

informer.on(‘add’, (obj: k8s.V1Pod) => { console.log(Added: ${obj.metadata!.name}); //Call out to some system here that might fail });

In the java we get to indicate with the reconcile return value that the event should get retried again in the future

public Result reconcile(Request request) { try { //do something that might throw an error } catch (Exception e) { LOG.error("Exception occured , e.getMessage(), e); return new Result(true); } return new Result(false); }

[brendandburns]

Of course it’s worth pointing out that the reconciler pattern has it’s own problems which is that you have to make sure that everything that you do is idempotent. e.g. if your handler makes some changes and then errors out and is re-run, you have to make sure that your handler can handle the partially complete state from the previous version.

[brendandburns]

I think that is a reasonable summary. In general, the Java client (and also things like the operator SDK in golang) have more extensive capabilities for writing more sophisticated operators. This isn’t really about the language but rather just who has been involved in the development of the client SDKs and how much time they have been able to dedicate to that development.

I’m going to rename this issue to reflect the feature request for a reconciler.