Define endpoint to retrieve status of all known LRAs in the system.

[rdebusscher]

We can define an endpoint, like /lra, which return the status (and the status of all participants for each LRA) of all known LRAs in the system.

This endpoint is not participant specific, but global to the deployment (like /metric a
nd /openapi)

A configuration option defines the time the LRA remains 'known' in the system after it has reached a final state. In that time, it is reported with the final state through this endpoint.

It SHOULD be possible to protect this endpoint.

Format JSON, data: To Be defined

[mmusgrov]

-1 We used to have query mechanisms in the project (recall LRAInfo etc) and I fought hard to keep them but the majority of the group asked for query mechanisms to be removed - there is a discussion history on the topic. Why the change of heart?

[mmusgrov]

The Narayana implementation uses the following JSON data: https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/LRAData.java#L6

but I think we could improve on that definition.

An example endpoint is https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L107. There are others in the same file which I think are probably overkill.

[rdebusscher]

I don't think we discussed an endpoint to view the LRAs known by the system.

This is not about participant retrieving the info of an LRA, but about governance.

[tomjenkinson]

We would want to consider this without the need for a centralised resource I expect.

[rdebusscher]

Works in the case of the solution chosen for Payara (which is also non centralised) but doesn't work in case of a routing-slip implementation. (thanks Martin for that remark)

[tomjenkinson]

I think this could be left to vendors to provide for now?

[xstefank]

We could still have an endpoint per microservice which would give only the information about the LRAs that the particular microservice knows of. Would that be useful?

But of course, we can mention that if the implementation is using a form of centralized coordination than there should be an endpoint exposing all LRAs.

[tomjenkinson]

I think this could be left to vendors to provide

[xstefank]

I think this could be left to vendors to provide

but better for it to be unified from the user perspective.

[tomjenkinson]

can routing slip achieve it?

[xstefank]

can routing slip achieve it?

Yes, because it will still travel between microservices. So individual microservices can expose an endpoint about processed LRAs.

[tomjenkinson]

I don't quite understand how routing slip would be able to collect a list of all LRA in the system? The propagated LRA would only know about it's own environment (and proceeding ones). In a centralised system all the LRA can be known, and in the case of totally decentralised is it possible to establish a list of all nodes that may have LRA in progress to collect this and return from a call to /lra

As I think a bit further /lra being an endpoint I am not sure how it would look in code and so on? We don't have a REST interface currently (IIRC we used to have this but removed it) for the @LRA methods but do a URI for a specific LRA so would need to consider that.

[xstefank]

@tomjenkinson in my comment above #175 (comment):

We could still have an endpoint per microservice which would give only the information about the LRAs that the particular microservice knows of. Would that be useful?

I was talking only about LRAs the service knows of. Did you possibly misread my intention?

To you second point: we can have /lra or something else in a similar manner as we have /health or /metrics.