[Fleet] Create API that queries remote kibana sync status API by output ID#217799
Conversation
|
Pinging @elastic/fleet (Team:Fleet) |
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/streams --include-path /api/fleet --include-path /api/dashboards --include-path /api/saved_objects/_import --include-path /api/saved_objects/_export --update'
| authz: { | ||
| requiredPrivileges: [ | ||
| FLEET_API_PRIVILEGES.SETTINGS.READ, | ||
| FLEET_API_PRIVILEGES.INTEGRATIONS.READ, |
There was a problem hiding this comment.
I think the flyout has to be adapted with the correct minimal privileges:
We should test that the API works correctly with a user role having only minimal privileges
|
|
||
| export const REMOTE_SYNCED_INTEGRATIONS_API_ROUTES = { | ||
| STATUS_PATTERN: `${API_ROOT}/remote_synced_integrations/status`, | ||
| INFO_PATTERN: `${API_ROOT}/remote_synced_integrations/{outputId}/remote_status`, |
There was a problem hiding this comment.
I changed the path to remote_status to clarify that is a different status than the above. We might need to fetch the global status remotely (i.e. without outputId) and in that case we could add another endpoint like this:
api/fleet/remote_synced_integrations/remote_status
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/streams --include-path /api/fleet --include-path /api/dashboards --include-path /api/saved_objects/_import --include-path /api/saved_objects/_export --update'
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
Hey @criamico I'm testing this afresh again and I'm seeing the following when running This seems to be fixed by adding the |
|
|
||
| return response.ok({ body: res }); | ||
| } catch (error) { | ||
| throw error; |
There was a problem hiding this comment.
Maybe a naive question: what is the benefit of catching and re-throwing these errors?
More generally, I was a little surprised to see thrown errors in kibana e.g. when the output doesn't exist (as opposed to a regular 404 response).
I think we don't need to return |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
Edit: a little late, sorry. Let me know your thoughts on the below. Hmm failed queries look different now. Example 1: incorrect remote Kibana URLResponse to Kibana logs: Example 2: incorrect output idResponse to Kibana logs: It looks like the added condition didn't work as expected? I don't want to block this PR, so I would say the previous version is more helpful. We shouldn't risk throwing 500s if the setup is incorrect. |
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]
History
cc @criamico |
|
@jillguyonnet the PR got merged, at this point this can be addressed in the next piece of work (probably the UI work at this point) |

Part II of #217025
Summary
Create API that queries remote kibana sync status API by output ID.
From the main cluster we call the remote kibana (simply using node-fetch) and query the endpoint added in #216178; this way the main cluster can have the status of the synced integrations on the remote cluster.
Testing
Note that dev_docs now have a guide to setup locally the remote clusters: https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/fleet/dev_docs/local_setup/remote_clusters_ccr.md
SyncIntegrationsTaskrunningremote_idis the id of the remote output configured on cluster A:The response should be the same as above
Screenshot
On Remote cluster (Cluster B):

On main cluster (Cluster A):
Checklist