-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Logs UI] Reimplement log source configuration routes in plain HTTP+JSON #64021
[Logs UI] Reimplement log source configuration routes in plain HTTP+JSON #64021
Conversation
Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui) |
@elasticmachine merge upstream |
There's a significant collision of intended goals with #64126, which I'll try to resolve. |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks / works great 👍 This will make the alerting stuff much easier 🙏
Just a few small comments.
type ValdidationResult<Value> = ReturnType<RouteValidationFunction<Value>>; | ||
|
||
export const createValidationFunction = <A, O, I>( | ||
runtimeType: Type<A, O, I> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small nit: I personally find generics easier / quicker to parse with meaningful type variables, could we change these from A, O, I
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I absolutely agree. I stuck with the io-ts naming scheme during experimentation and forgot to clean it up afterwards.
@elasticmachine merge upstream |
merge conflict between base and head |
@Kerry350 I had to adapt the mount location of the view-in-context-related component hierarchy to make sure the providers are available. I'd appreciate a second pair of eyes on that to ensure I haven't broken the view-in-context modal if you have the time 🤔 |
LGTM 👍 |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
Summary
This reimplements the parts of the source configuration GraphQL API relevant for logs in HTTP+JSON. The source configuration UI components specific for the Logs UI are moved to the
pages/logs/settings
directory.The storage layer is not changed, so the saved object is still shared with the Metrics UI. But this separation on the route level prepares for an eventual split of the source configuration storage mechanisms.
The source status is implemented as separate route to allow for lazy field cap querying (see phase one of #53138).
It leaves the previous GraphQL resolvers in place for use by the Metrics UI. They will be removed along with the whole GraphQL endpoint in a later PR (see phase two of #53138).
New routes
GET /api/infra/log_source_configurations/{sourceId}
Get a log source configuration from the saved objects or the defaults.
PATCH /api/infra/log_source_configurations/{sourceId}
Update a log source configuration's saved object.
GET /api/infra/log_source_configurations/{sourceId}/status
Get the index names and field list pointed to by a source configuration.
Testing
Some points to have an eye on:
/api/infra/log_source_configurations/...
endpoints.Follow-up tasks