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.

[tomjenkinson]

I think the important part is defining what comprises the system in the following:

return the status (and the status of all participants for each LRA) of all known LRAs in the system.

[xstefank]

@tomjenkinson I understand that this was the original proposal but I proposed something slightly different and I thought you are reacting to my comment #175 (comment).

I still think that the variation of Rudy's idea can be specified.

[rdebusscher]

The reasoning behind my proposal is that such a list could help as there are scenarios where manual actions are required in case automatic completing or cancelling fails.

It is easier to retrieve the information for the action points from an endpoint then to parse the log files (as such situations needs to be logged according to the current spec)

A single endpoint for all LRA information is easier as developers don't need to call several endpoints to gather that information.

When using routing slip as implementation, this global endpoint is not possible.

[rdebusscher]

So an updated proposal is to have either a single endpoint that returns all information or an endpoint per service which returns service-specific information.

[xstefank]

Or both :)

One thing. We're really hypothesizing about routing slip. So why can't potential routing slip implementation implement "another" routing slip that would collect and aggregate the information from all microservices in the system? And this functionallity can be exposed by any service in the system. -- really just an idea. I would definitely like to see something like this suggestion in the later version of the spec.

[tomjenkinson]

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?

Have you a suggestion on how an interested party could discover all the endpoints?

[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?

Have you a suggestion on how an interested party could discover all the endpoints?

I don't understand how that relates to the text you've copied but service discovery is a solved problem in microservices architectures (otherwise the microservices cannot communicate with each other). You only need to know one endpoint which is probably going to be one you're communicating with.

[tomjenkinson]

The requirement as expressed was to find the status "of all known LRAs in the system" so without knowing who is in the system I am not sure how to collect the results of all "/lra" calls