Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Logs+] Create an integration while on-boarding logs (#163219)
## Summary This closes #161960, a basic integration will now be created whilst onboarding logs (though the custom logs flow). This implements the *initial* version of this work, and does not include things like adding a dataset to an existing integration. ## UI / UX General: ![Screenshot 2023-08-07 at 15 20 21](https://github.com/elastic/kibana/assets/471693/3ca4e300-41c3-4554-a095-0f3dcf9e9523) Naming conflict errors: ![Screenshot 2023-08-11 at 13 34 45](https://github.com/elastic/kibana/assets/471693/2a138eac-73e2-4cc9-b1e8-56c586b852ee) ![Screenshot 2023-08-11 at 13 34 59](https://github.com/elastic/kibana/assets/471693/6e651de9-debd-46aa-a3d5-2b6eb4e3bb4f) Lack of permissions error: ![Screenshot 2023-08-09 at 17 10 35](https://github.com/elastic/kibana/assets/471693/d47b40c8-fe4a-4b86-abf8-d8fda51515fd) General errors: ![Screenshot 2023-08-07 at 16 49 40](https://github.com/elastic/kibana/assets/471693/346c28d0-ec3e-4f7e-ae16-3f1adf440c21) Success callout on the next panel: ![Screenshot 2023-08-07 at 17 20 45](https://github.com/elastic/kibana/assets/471693/03e78e45-871b-4224-9999-5b3d7e2ccdf0) Delete previous flow (happens in the background): ![delete_process](https://github.com/elastic/kibana/assets/471693/44c18793-9df7-4228-b351-5668f098e138) ## Pointers for reviewers / next steps - This PR also creates a new package for the `useTrackedPromise` hook, as this is used in several places and I didn't want to just duplicate it again (I haven't replaced other current uses in this PR, but will as a followup). - `useFetcher` was avoided as A) it's very tightly coupled with the observability onboarding server route repository (and `callApi` is scoped to this) and I wanted to call an "external" API in Fleet and B) I wanted explicit control over when the request is dispatched (not on mount), and whilst this can sort of be achieved by not returning a promise from the callback it gets quite messy. I also wanted more granular error handling control. - Moving forward I think we'll need to enhance the state management of the plugin. We'll want to add the ability to "add to existing integration" and this is going to make the state more complex (even with chunks of this functionality likely moved to it's own package). I did actually have the Wizard state moved in to a constate container at one point (as a starter) but I reverted this commit to make the changeset less intrusive. It's for this same reason that, for now, I haven't focussed too closely on extracting things like generating the friendly error messages etc as we'll likely want to extract some of the "create integration" hooks / UI in to a standalone package so they can be used elsewhere (not just onboarding). There are also quite a few ` eslint-disable-next-line react-hooks/exhaustive-deps` rules in the plugin at the moment due to the references not being stable, we could improve that at the same time as any state changes. - You can technically navigate directly to `/fox/app/observabilityOnboarding/customLogs/installElasticAgent`, but no state is stored in the URL, so nothing is rehydrated resulting in a very empty configuration. I'm not entirely sure this is a behaviour we want, but for now I've just made the callout conditional on state existing (so coming from the previous panel). - The Fleet custom integrations API now throws a 409 (conflict) when using a name that already exists. ## Testing - Head to `/app/observabilityOnboarding` to trigger the onboarding flow - Select "Stream log files" - When hitting "continue" an integration should be created in the background (check the network requests for `api/fleet/epm/custom_integrations`) - When continuing (to install shipper), then going back **and** making changes to your integration options, when clicking continue again there should be a network request that deletes the previously created integration (to clean things up). This should be seamless to the user. - You should not be able to use a name that already exists (for an existing custom integration) - General errors (like permission issues, asset installation issues) should display at the bottom - When you hit the next panel (install shipper) there should be a success callout that also contains the name of the integration that was created ## In progress ~Two changes still in progress, but they don't need to hold up the review (8.10 coming soon 👀):~ - ~To have a friendlier error for permissions issues (not just "forbidden")~ - ~Fleet API integration test for the naming collision~ --------- Co-authored-by: kibanamachine <[email protected]>
- Loading branch information