[Epic] Pluggable Discovery Services #936
Labels
feat
New feature or request
high-priority
needs-documentation
question
Further information is requested
For Cryostat 2.2.0, we want to enhance the flexibility of the target discovery mechanism. Currently this is encapsulated in the Platform Module, in particular the Platform Detection Strategy and the Platform Client. This allows Cryostat to have some flexibility in determining where it is running and how it should discover target applications. But there are pitfalls:
Endpoints
and looking for ports with number9091
or namejfr-jmx
. They cannot customize the behaviour to use k8s Annotations or Labels or any other custom logic for their deployment.ServiceRef
that represents a single target application, and the newer hierarchical design ofEnvironmentNode
/TargetNode
used in the Discovery tree API./api/v1/targets
,/api/v2.1/discovery
, and a few different queries under/api/beta/graphql
. We should at least deprecate/api/v1/targets
and replace it with an API V2+-compliant endpoint. The response data format here should match/api/v2.1/discovery
and the GraphQL query responses as closely as possible.mylabel=foo
". This need is served by GraphQL already from a client perspective, but on the backend the implementation is quite inefficient, since it performs a full platform query to determine the overall graph structure (see point 4 again), and then applies the specified property filters to the results. The implementation that solves points 3 and 4 should also lend itself to re-implementing this point more efficiently.The text was updated successfully, but these errors were encountered: