Create basic integration API prototype #160003
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
|
Hi folks, would you mind taking a look at this to validate the approach? (the code is just rough). The prototype issue that pairs with this is here: #158552 Specifically I have written up what I learnt and information on this prototype here: #158552 (comment) Felix has also written up an issue for the real implementation here: #159991 which contains some open questions from our findings. |
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
To update your PR or re-run it, just comment with: cc @Kerry350 |
|
@nchaulet @juliaElastic would you mind just taking a look at this PR and give Kerry a 👍 if this approach is aligned with our practices. |
|
@Kerry350 Sorry for the late response. |
|
Closing this just so we can keep the conversations in #160777. |
## Summary Closes #159991 Fields that have been utilised to fulfil `basic` and `agent` fields can be easily amended if these are incorrect. Multiple datasets are supported, and these can contain more than one type. ## Testing A curl command similar to the following should allow you to hit the API (check the credentials etc): ``` curl -XPOST -u 'elastic:changeme' -H 'kbn-xsrf: something' -d '{ "integrationName": "web_custom_nginx", "datasets": [{"name": "access", "type": "logs"}, {"name": "error", "type": "metrics"}, {"name": "warning", "type":"logs"}] }' 'http://localhost:5601/<BASE_PATH>/api/fleet/epm/custom_integrations' ``` ## History / context - [Prototype learnings](#158552 (comment)) - [Prototype PR](#160003) ## Results / expectations API response (with installed assets):  We see the custom integration in "installed integrations" (albeit with a verification warning):  We see the custom integration in Discover with the logs explorer profile:  The assets are installed correctly:   
Summary
It's purpose was for R&D and to prove this was possible, the code is not perfect. However, whilst the code is rough, this is the overall approach that we want to validate. Unless there are issues or objections we will move forward with the approach (although cleaner) in #159991.
In a real implementation we would, for example, place the asset generation in to separate functions (possibly a package), and a proper library would serialize to YAML rather than just throwing brittle strings around. We could also place this in a new "custom" fork within the normal install method etc.