-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Connectors][API] Update connectors with enabledAfterImport flag #94106
Comments
Should we be able to disable preconfigured connectors? My feeling is no. If it's preconfigured and users want to move to a different cluster, they can copy the |
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
Yeah, that seems correct. The secrets for preconfigured connectors are either in the config as well as the other params, or can be in a a keystore. So they already have a mechanism for "import/export". |
A couple of sharp edges to watch out for when adding new fields the connector saved objects:
|
That's going to be complicated. We already have a mix of secrets which are nullable, and some are not. How would we know then if a particular secret is "really" nullable or not? Could we just set the ... sorry, starting to ramble below, but given the number of APIs we're adding, now wondering if there is some "simpler" story ... I'm kinda wondering if we even need to support specific enable/disable APIs. During export, we would presumably not export the secrets, but then we can't do an import of those using existing APIs as the validation would fail because there are no secrets (except for server log and the index connector since they don't have secrets :-)). We'd need a special import API that would allow connectors to be created but not validate their secrets. Those connectors would then fail if you ever tried to run them (we validate before running), and require that the customer update the connector to add the secrets back. What we'd be missing is a clear signal that there are connectors which need their secrets added back, since we don't really have a way of showing that now. But maybe that's just some hidden field, which we set on the special import API, and can show an indication in the alerts list (and make it sortable/etc) - I guess this is the It does make me wonder in general how we will ensure that server log and the index connector will get exported and then imported without requiring any user interaction! Interesting edge case! Also I'm wondering if we have use cases where we would want to enable/disable connectors independent of import/export - we've talked about it before, but I'm not sure we have any real requirements for it. Having to deal with |
My thinking behind this was since the workflow user imports connectors that are disabled and are directed to the connectors list to re-enable and re-enter secrets, each connector in the list would have some sort of enable switch (like the rules list does currently). If there is an enable, then there probably should be a disable :) However, I see your point that this is a lot of API changes. Maybe if we consider the re-enable workflow more of prompting the user to edit their connector instead of re-enabling it, we can get away with just updating the update API instead of introducing the concept of explicit enable/disable. I do think it would be useful to have a disable by ID API (maybe a connector is erroring; user could disable it while troubleshooting to avoid littering the logs with errors and then reenable later without having to go through all the alerts to figure out which ones used the connector, which they would need to do if they deleted the connector). But maybe this isn't something that needs to happen now? |
The import process would happen at the core SO layer, which bypasses our logic (including validation). This would allow objects to be imported as-is even if validation fails. We would then have to handle such a scenario. |
It doesn't need to happen now, but would be nice to kill two birds with one stone. OTOH, it adds more moving parts that we don't explicitly need for export/import. I'm thinking that if we add enable/disable in this PR, and we end up putting newly imported connectors in a disabled state, we will probably want a "disabled reason" field, so we can distinguish "a user explicitly disabled this" vs "this was disabled because it was just imported", so we can distinguish the two. |
@mikecote cleared up some confusion I was having about using the saved objects import/export vs using our own API and I think we can simplify this a little to (1) remove changing the secrets to nullable and (2) remove the suggested We can avoid changing the secrets to nullable since the import/export process bypasses our validation altogether. If we use a variable like If we do it this way, then enable/disable is kind of a completely separate issue. If we're good with this, I'll update the issue description. |
That sounds good to me. |
I'm +1 on that idea as well 👍 |
I might be missing something, but I don't feel the name I'm not sure the name Any thoughts? |
@gmmorris Naming is hard :) When I see |
It's the worst.
Yeah, that would be better for sure... I'm still not sure I'd understand what the call to action is 😬 |
In order to support import/export of connectors, we need to mark a connector as enabled/disabled after import. This issue addresses the API portion of this. A separate issue has been created for addressing the UI portion.
enabledAfterImport
flag (or something similar) toRawAction
typecreate
andupdate
should just setenabledAfterImport
totrue
enabledAfterImport: true
to all existing connectorsThe text was updated successfully, but these errors were encountered: