You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I agree that what we really should provide is a positive list of which elastic/integrations are supported (although since we do not own them, keeping this in-sync is going to be tricky).
From our existing positive list of what we do support, we could fairly easily script something that validates individual integrations with some caveats:
we support integrations whose default pipeline is wholly-comprised of supported processors whose if and on_failure clauses are also wholly-comprised of supported processors.
the pipeline processor is supported if-and-only-if the pipeline it references is fully-supported
pipelines referencing {{ IngestPipeline "XYZ" }} in elastic/integrations are effectively package-local, so in PACKAGENAME/data_stream/elasticsearch/ingest_pipeline/default.yml{{IngestPipeline "third-party" }} references PACKAGENAME/data_stream/elasticsearch/ingest_pipeline/third-party.yml:
IngestManager / EPM replaces '{{IngestPipeline "some-pipeline" }}' with "PACKAGEPREFIX-some-pipeline".
PACKAGEPREFIX will look like: "logs-PACKAGE.DATASET-VERSION".
We rename all pipelines before installation by prefixing them with PACKAGEPREFIX so the name of the referenced pipeline matches.
-- issue comment in elastic/integrations#14
if a pipeline otherwise references a pipeline by mustache template we may not be able to recurse
Document that the following processors are not supported and why are not supported.
Ideally, we should be able to document which integrations are supported more-so than processors.
The text was updated successfully, but these errors were encountered: