Skip to content
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

[ResponseOps][Connectors] prevent or allow connectors with pre/post save/delete hooks from being used as pre-configured connectors? #195824

Open
pmuellr opened this issue Oct 10, 2024 · 4 comments
Assignees
Labels
Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@pmuellr
Copy link
Member

pmuellr commented Oct 10, 2024

based on PR comments:

Originally this was titled "prevent connectors" without the "or allow", but I guess we're still figuring it out, and it looks like we will likely need to allow them.

If we wanted to prevent themwe should be able to - at startup - mark pre-configured connectors as disabled (or unusable, somehow), if their connectorType has pre-save/post-save/post-delete hooks. Since the hooks will never be called since the connector is never "created" or "deleted" via API.

If we want to allow them, we need to figure out:

  • how the inference the connector normally creates in it's pre-save hook, actually gets created, since the create code is not called
  • I could see some ways of getting the inference created, but no idea how we'd go about deleting it. I guess in theory, it would never need to be deleted, since the pre-configured can't really be deleted (unless the pre-configured connector is removed from config and then Kibana restarted.

Once we figure out which way to go, we can aim this issue down that track, or leave this as discussion and create a new one ...

@pmuellr pmuellr added Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Oct 10, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

@pmuellr
Copy link
Member Author

pmuellr commented Oct 10, 2024

Note this was a little premature - actually an inference connector DOES need to be pre-configured - some conversation here:

#189027 (comment)

We can use this issue to discuss how this can happen, I'll swizzle the title and top comment ...

@pmuellr pmuellr changed the title [ResponseOps][Connectors] prevent connectors with pre/post save/delete hooks from being used as pre-configured connectors [ResponseOps][Connectors] prevent or allow connectors with pre/post save/delete hooks from being used as pre-configured connectors? Oct 10, 2024
@pmuellr pmuellr self-assigned this Oct 18, 2024
@pmuellr
Copy link
Member Author

pmuellr commented Oct 24, 2024

@YulNaumenko Have we decided on whether we need to allow this, or prevent this, for now? Currently we would allow them, but don't have any code to make the ES /inference call for these.

@YulNaumenko
Copy link
Contributor

Have we decided on whether we need to allow this, or prevent this, for now?

The lifecycle hooks doesn't seem to be very useful for the preconfigured connector overall. I don't see when they should be executed at all, maybe I'm missing something.
What we definitely might need to have is the ability to check if the Inference Endpoint by ID exists when using the connector within UI or API (at least execute method) and show the proper error in UI or API.

how the inference the connector normally creates in it's pre-save hook, actually gets created, since the create code is not called

The reason why we need preconfigured connector for Inference is when we are going to provide to our users the Elastic default models - hosted by Elastic.
For the regular Kibana users who wants to make own Inference connector the preconfigured way, we may well document it that first they need to create the inference endpoint and then make from it the preconfigured Inference AI connector.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

No branches or pull requests

3 participants