Intro
Elastic currently supports 300+ integrations via Elastic Agent, to ingest data from common data sources across security and observability use cases. All integrations are treated equally from a support standpoint regardless of where the integration came from. We have three main sources of integrations:
- Elastic integration teams (including contractors)
- Vendors who build integrations for their products under our partnership program
- Community users who develop and contribute integrations
While we really appreciate and value community contributions, we are limited in our ability to test these integrations as we typically don't have access to the data source and don't have a technology partnerships in place with the vendor. Similarly, for vendor/partner developed integrations, while we review the PR, we didn't build the integration and can't guarantee the same quality as Elastic developed integrations.
Proposal
In order to set expectations with users on the quality and support they can expect from an integration, we should highlight the source of the integration within integration documentation and on the integrations UI. We will continue to provide best effort support and don't want situations where users adopt community developed integrations that are completely unsupported. However, expectations should be set that Elastic has not developed these integrations, does not have access to the data source and to expect possible parsing/mapping/performance issues.
We need to finalise wording and ensure we set user expectations correctly, but something similar to Hashicorp's community supported wording is what we're aiming for:
**Community Supported** – the S3 storage backend is supported by the community. While it has undergone review by HashiCorp employees, they may not be as knowledgeable about the technology. If you encounter problems with them, you may be referred to the original author.
To Consider
- All integrations, regardless of the source, reside in the elastic/integrations repo. Should we consider moving community and/or technology partner integrations to a separate repo? How would Elastic Package Registry handle this?
- Beyond a section within the documentation, could we add attributes to the packages and make those attributes visible in Fleet. e.g. Developed by
- Within Fleet could we add a filter based on integration source? e.g. Elastic, Vendor, Partner (unsure on the value of this, but worth considering at least).
Tasks
Intro
Elastic currently supports 300+ integrations via Elastic Agent, to ingest data from common data sources across security and observability use cases. All integrations are treated equally from a support standpoint regardless of where the integration came from. We have three main sources of integrations:
While we really appreciate and value community contributions, we are limited in our ability to test these integrations as we typically don't have access to the data source and don't have a technology partnerships in place with the vendor. Similarly, for vendor/partner developed integrations, while we review the PR, we didn't build the integration and can't guarantee the same quality as Elastic developed integrations.
Proposal
In order to set expectations with users on the quality and support they can expect from an integration, we should highlight the source of the integration within integration documentation and on the integrations UI. We will continue to provide best effort support and don't want situations where users adopt community developed integrations that are completely unsupported. However, expectations should be set that Elastic has not developed these integrations, does not have access to the data source and to expect possible parsing/mapping/performance issues.
We need to finalise wording and ensure we set user expectations correctly, but something similar to Hashicorp's community supported wording is what we're aiming for:
**Community Supported** – the S3 storage backend is supported by the community. While it has undergone review by HashiCorp employees, they may not be as knowledgeable about the technology. If you encounter problems with them, you may be referred to the original author.To Consider
Tasks
Add owner.type field to indicate package support level package-spec#568
Set owner.type field as required package-spec#604
sei: Update packages to format_version 3.0.0 #7810
Change owner type for SEI packages not owned by Elastic #8035
[Fleet] Display
owner.typefield from package manifest on integration overview page kibana#167981https://github.com/elastic/integration-docs/issues/255