Discuss expectations when 3rd party services break our connectors

[mikecote]

I'm creating this issue so we can discuss what the expectation is when 3rd party services change or remove something that breaks functionality in our connectors.

Example

Slack removing an API in favour of another.

Questions:

• What is the expectation for unsupported versions of Kibana?
• What is the expectation for supported versions of Kibana?
• How do we keep track of these 3rd changes so we can be proactive about them?

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[mikecote]

The question originated from @bmcconaghy with an option to package 3rd party connectors (using EPM?) so updates can be pulled from a registry. This works well with the licensing model as they don't require to be built-in as they don't rely on basic.

[pmuellr]

Interesting approach to using EPM or similar, some research will be required, but here's some soft balls :-)

• can we ship code in EPM packages? I think if we did, we'd want to ship JS so we wouldn't have to deal with TS compilation on the fly, so how do we "build" these?

• do EPM packages have a notion of stack versions they are compatible with? We may have to ship multiple versions of the same action type for different stack versions, which may get complicated. On the plus side, this means we could "fix" versions of actions running in old stack versions without waiting for a stack version patch (for which there might not be one).

• we'll have to expose the whitelist/proxy stuff (already an issue: [Alerting] action validators should be passed allow-list config utils #64659)

• seems like this potentially opens the door for customers to create/install their own actions, which will be a licensing issue

[pmuellr]

As just a first, baby step here, we should probably make a list of the 3rd party services we use, along with the "version" of their API that we are using (if available); sometimes we use 3rd party libraries (eg, Slack), so having the npm version we are using would be nice.

I'm thinking that we might even want to reference this info in our doc. Could help customers diagnose issues, if they know which APIs we're using so they can do their own research - or they may have more familiarity with some services than we do.

[kobelb]

I think we should use our maintenance policy to guide this decision.

Our goal is to maintain the most recent minor release from the current major release stream and the most recent minor release from the prior major release stream.

We only commit to fixing bugs in the versions that we maintain. If a connector to a third-party API breaks, I think we should treat this as a bug and fix it in any versions that we maintain. We've already set the expectation with our users that they should be upgrading to a maintained version if they want to ensure that things continue to work correctly.

We already have a precedent set in this regard, with regard to breaking changes introduced by browsers. When a browser does something like change the defaults for SameSite we only ship what we consider to be the fix in maintained versions.

[mikecote]

Our goal is to maintain the most recent minor release from the current major release stream and the most recent minor release from the prior major release stream.

We have an existing example now where MS Exchange will remove basic authentication support and "break" existing functionality for those using the email connector with MS Exchange (#93466). To fix this, we may need to enhance the email connector to support OAuth (#93466 (comment)).

If this exercise were to happen during 8.x and based on our current maintenance policy, we would need to backport this new feature in a 7.16.x patch release? 🤔

@arisonl @kobelb @stacey-gammon @alexfrancoeur heads up that I'll start an offline discussion around this topic to validate expectations and gain alignment.

[alexfrancoeur]

Thanks for raising this @mikecote. In those discussions, it'd be good to align on two things. Current expectations and future. I imagine the latter will be less defined, but I think we can agree on a general direction.

[kobelb]

We have an existing example now where MS Exchange will remove basic authentication support and "break" existing functionality for those using the email connector with MS Exchange (#93466). To fix this, we may need to enhance the email connector to support OAuth (#93466 (comment)).

If this exercise were to happen during 8.x and based on our current maintenance policy, we would need to backport this new feature in a 7.16.x patch release? 🤔

That's my understanding, yes. I don't see it in the maintenance policy, but I recall prior situations where bug-fixes couldn't realistically be backported to the n-1.last release (with n representing the current major version), so we might have some discretion when bug-fixes are infeasible. However, if we're breaking a major feature that a large number of users rely on, this sets the bar rather high.

[mikecote]

Closing issue as we now know the support expectations whenever this does occur.