[Fleet] Label beta and experimental inputs

[mostlyjason]

Problem

Currently, our integrations page shows GA, beta or experimental for each integration. However, each input in Elastic Agent can be GA, beta or experimental. This will be confusing to users because if they see an integration labeled as GA, they'd expect the inputs to be GA as well. To avoid setting incorrect expectations, we need to show our support policy at a lower level of granularity.

We label each input as experimental or beta in our documentation, but users do not see this without leaving the product and there are no links to the input docs. It is not easily discoverable when adding or editing an integration.

Solution

Let's update our integration policy editor page to include a label next to each beta or experimental input. For example, if the input apache/metrics is beta, here is what we could show:

Ideally, we'll define the support level for inputs in Kibana as opposed to in the package spec because the agent is versioned with the stack, and it won't require package authors to remember to add or update it.

Also, the input support level depends on the agent version. We generally recommend (but don't require) that users upgrade their Elastic Agents to the Kibana version. We could include some hovertext to be more explicit:

This is a {beta} input in Elastic Agent version {kibana version}. This functionality is in beta and is subject to change. The design and code is less mature than official GA features and is being provided as-is with no warranties. Beta features are not subject to the support SLA of official GA features.

Open questions

1. Do we have any use cases for a different support level for each type of OS for a given input? For example, do we need an input to be GA on Linux and experimental on Windows? Note that if an entire integration is supported only on specific OSes (eg. the Windows integration), that can be communicated at the integration level.

CC @nimarezainia @andresrc @urso @ruflin

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[jen-huang]

Ideally, we'll define the support level for inputs in Kibana as opposed to in the package spec because it will be easier to update with each release, and it won't require package authors to remember to add or update it. We'll also need to label each input as experimental or beta in our documentation.

This will be possible only if we determine status based on input type only (logs/metrics), but not if we want to determine it by package and input type. We don't want Kibana to have knowledge of specific packages. In that case it is much better to have this defined on the package side.

Edit: Also, I'm moving this to backlog.

[mostlyjason]

@nimarezainia @urso I believe the inputs are defined as GA, beta or experimental regardless of what package they are defined in. The documentation shows the beta messaging at the input level. For example, I see that the unix input is beta https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-unix.html. This would apply to all integrations that use the unix input? Can you confirm?

[mostlyjason]

@masci @sorantis Do we have any use cases for a different support level for each type of OS for a given input? For example, do we need an input to be GA on Linux and experimental on Windows? Note that if an entire integration is supported only on specific OSes (eg. the Windows integration), that can be communicated at the integration level

[sorantis]

Can't think of any OS-specific differences but as you pointed out in earlier in the issue we do have multiple cases where a module is GA but some of the metricsets or filesets are still in Beta.

[mostlyjason]

Another use case is that an integration package can define whether an input is beta or not. This means the badge we show should be the minimum of the integration package release status and the elastic agent input release status. For example, the Splunk input is experimental but the Elastic Agent input is not.

[nimarezainia]

Agreed that we need to mark and make it obvious which inputs are Beta - despite the status of the integration they enable (or are utilized by). Right now I don't think there is a single location that lists all the inputs and whether they are GA or Beta. I think we need such source of truth in order to be able to build what's being requested here.

@andresrc @ruflin : Your thoughts on this? is it worth creating a file in our repo that does this? and the fleet team could reference that to determine whether the "Beta" keyword is required?

[andresrc]

We have that information at the dataset level, afair, and that should be our source of truth. If a dataset relies on an non-GA input, it should be marked as non-GA

[ruflin]

I would rely on the package developer to make the decision. If a dataset relies on a beta input, it should also be beta. But it can also be that a dataset relies on an input that is GA but it is still beta. To take this further, it can also be that a dataset itself is GA but a new config option that was added is in beta.

There is another scenario here around versions. Lets say input foo is beta at the time package bar was built. Now foo is released as GA but still package bar is used. It will still show as beta and this is fine. As mentioned before, it is up to the package dev to release a new version of the package and marking the bar dataset as GA.

The user itself should not care about if an input is GA but only if the dataset is GA.

[andresrc]

That's a better explanation of what I meant. Agree

[mostlyjason]

@ruflin in order for the package developer to release the bar dataset as GA in that scenario, I think they'd have to add a constraint that the package requires the elastic agent version where foo is GA? Otherwise, the user could have a scenario where the bar dataset is GA but its running on an agent where foo is still beta.

Is it an acceptable compromise to force users to upgrade their agent to get an updated package? Also, should we trust package authors (particularly third party ones) to set their datasets to the release status of agent with appropriate constraints?

The advantage of decoupling the input release status from the dataset release status is that we don't need to force upgrades for users, and we don't need to trust package developers to get it right. We can enforce it on the platform (Kibana) side.

I'm curious what you think. I just want to make sure we consider the pros/cons of the options.

[ruflin]

I think the problem is even more complicated than that as the users will have over time multiple versions of Elastic Agent running likely even under a single policy. We likely need to separate two parts:

• What we show during configuration, is the configuration block the user is using GA. This is where I would follow my previous recommendation around package dev decides it.
• Running Agent: Is the running Agent running a beta input. I would expect this to be reported by the Elastic Agent to Fleet and we likely could visualise it.

We likely need to get into requiring a specific version of the Elastic Agent at some point as this is not only about beta / GA but it might also be that an input does not exist in certain Elastic Agent versions yet or even is blocked in the capabilities. Should we open a parallel thread to discuss this further?