Composable packages: input `name` qualifiers and stream `input` refs by teresaromero · Pull Request #3480 · elastic/elastic-package

teresaromero · 2026-04-20T12:36:20Z

Why

Composable packages with requires.input can have multiple required inputs of the same type. package-spec#1135 (3.6.0+) requires distinct policy_templates[].inputs[].name and streams[].input that reference that name—not a single derived id for both policy and streams. elastic-package previously did not match that pattern, which caused ambiguous Fleet policies and errors (e.g. missing stream templates).

This branch also builds policies from the built package manifest (so composable package: refs resolve for Fleet), adds CI/fixtures (nginx composable, dual same-type inputs, bootstrap input pkgs), and includes data_stream.type for input-package system/policy tests (#3509) plus docs for Kibana/Fleet version behavior.

What changed

internal/requiredinputs / internal/kibana / internal/packages / internal/resources/fleetpolicy: Stable input name when types collide; type stays the agent type; streams use inputRef (name or type); PackagePolicyInput.inputType is the Fleet input type; FindInput matches name or type. Policy built from built tree (ReadBuiltPackageManifest, etc.).
Test runners & scripts: Policy/system/script updates for composable flows, overrides, and data stream naming; composable Makefile/script and packages under test/packages/composable/ and test/packages/parallel/nginx_composable/.

How to verify

go build ./... / go test ./... (see AGENTS.md for narrower scopes). Composable: Makefile + scripts/test-composable-packages.sh. Example: go run . test -C ./test/packages/parallel/nginx_composable on a stack with the Fleet fixes you need. go test ./internal/kibana/... ./internal/testrunner/... for golden/policy coverage.

Depends on

Stack: Snapshots (or pins) that include the Fleet fixes your integration tests assume—align CI stack version with what you document. data_stream.type: Use policy_api_format: legacy where the simplified API still rejects the var (kibana#266321); see howto docs.

…e-type inputs When a composable policy template ends up with multiple required input packages that share the same type (e.g. two otelcol inputs), set a unique name on each input derived from the required package name so Fleet can disambiguate them (package-spec SVR00010). Data stream manifests then reference inputs by name instead of type, matching the Fleet/Kibana expectation from package-spec 3.6.0+. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…fiers Updated the logic in `BuildIntegrationPackagePolicy` to utilize a unique name qualifier for inputs that share the same type, ensuring proper disambiguation in data stream manifests. Introduced the `inputRef` function to determine the correct identifier for inputs based on their name or type. Enhanced the `FindInput` method in `PolicyTemplate` to accommodate this change, allowing for more flexible input resolution. Added tests to validate the new behavior with dual input packages.

…release version - Added a temporary replace directive in go.mod for github.com/elastic/package-spec/v3 to use a pre-release version until the official v3.6.1 is released. - Updated go.sum to reflect the new dependency version and its associated module information.

…able/input-name

… v3.6.1 Removed temporary replace directive for github.com/elastic/package-spec/v3 and updated go.sum to reflect the stable version 3.6.1. This change ensures the project uses the official release instead of a pre-release version.

… to ^9.4.0 Created new stack version files for composable packages, all set to version 9.5.0-SNAPSHOT. Updated the Kibana version requirement in the manifest files of existing packages to ^9.4.0 for compatibility.

…iable setup Updated the test-composable-packages.sh script to include environment variable exports for PACKAGE_TEST_TYPE and PACKAGE_UNDER_TEST. This allows for better configuration of stack version and provider settings during testing, improving the flexibility of the testing process.

…bootstrap inputs Updated the test-composable-packages.sh script to build and install multiple bootstrap input packages in a defined order. This change enhances the testing process by ensuring that all necessary input packages are handled correctly before and after the stack is set up, improving the overall reliability of the composable package testing workflow.

teresaromero · 2026-04-22T09:34:02Z

test integrations

elastic-vault-github-plugin-prod · 2026-04-22T09:39:53Z

Created or updated PR in integrations repository to test this version. Check elastic/integrations#18579

mrodm · 2026-04-22T09:36:16Z

+	for i := range pt.Inputs {
+		input := &pt.Inputs[i]
+		if (input.Name != "" && input.Name == identifier) || input.Type == identifier {
+			return input
+		}
+	}


Q: Should this loop duplicated to first look for input.Name and if it does not find any , then look for input.Type ?

Is it ok to search at the same time for both ?

as defiened on spec https://github.com/elastic/package-spec/blob/61cee23beb811b6c93ddb71caf822914ee30afba/code/go/internal/validator/semantic/validate_integration_input_qualifier.go#L68 the propoerty name is required when inputs share the same type. so i think is safe to make this comparison, so when name is found, its due to the fact that type is the same. when name is not found (empty) then we can trust type

mrodm · 2026-04-22T10:02:02Z

+if [[ -z "${PACKAGE_UNDER_TEST:-}" ]]; then
+  export PACKAGE_UNDER_TEST="${COMPOSABLE_STACK_PIN_PACKAGE:-${COMPOSABLE_INPUT_PKG}}"
+fi


As this test script is intended to test all packages at the same Buildkite step, I was wondering that it could be set directly in the elastic-package stack up command the required verion.

Helpers for doing this task, just ignore the targets that do not set PACKAGE_UNDER_TEST

stack_version_args() { if [[ -z "${PACKAGE_UNDER_TEST:-""}" ]]; then # Don't force stack version if we are testing multiple packages. return fi ...

It would be needed to add a TODO note to remove that version once the default one in elastic-package is the right one (or create an issue for that ?)

i've added the version flag to the command directly on the script. does it make more sense?

Yes, let's keep it as that for now.

mrodm · 2026-04-22T10:03:14Z

Given how the Buildkite step works for this new test step, just one file should be needed because there is just one Elastic stack started.

Given that, I was wondering if it could be just pinned in the shellscript adding a TODO to remove it (or maybe an issue). WDYT?

mrodm · 2026-04-22T10:10:51Z

 					Enabled:        enabled,
 					Streams:        streams,
-					inputType:      streamInput,
+					inputType:      input.Type, // always the real agent type, not the name qualifier


Q: So then here, would be "metrics", "logs", "traces" or "otelcol"?

these are the agent input types, not the data stream types, added a comment for clarification

… definitions for access logs and updating policy files to include data stream structure. Introduced expected output files for both access and stubstatus data streams to improve testing coverage.

… package testing Modified the Makefile to set PACKAGE_TEST_TYPE for the test-build-install-packages-composable target. Updated the test-composable-packages.sh script to clarify the usage of PACKAGE_TEST_TYPE and ensure proper environment variable handling during testing.

Eliminated the FindInputByType method from the PolicyTemplate struct to streamline the codebase. This change simplifies the input retrieval process, as the method was not utilized in the current implementation.

…le-packages.sh Deleted obsolete stack version files for composable packages, which were all set to 9.5.0-SNAPSHOT. Updated the test-composable-packages.sh script to streamline the handling of PACKAGE_UNDER_TEST, ensuring better clarity and functionality in the testing process.

…rationPackagePolicy Updated comments for the inputType field in PackagePolicyInput and the BuildIntegrationPackagePolicy function to provide clearer explanations regarding the Fleet agent input type, distinguishing it from name qualifiers and data stream types.

… configurations Introduced a new stack version file set to 9.5.0-SNAPSHOT. Updated the configuration files for access and stubstatus data streams to include a data_stream structure, enhancing the organization and clarity of variable definitions.

…able/input-name

…e input refs Source manifests for composable integrations carry unresolved `package:` references in stream/input definitions; RequiredInputsResolver only materialises these during the build step. Using source manifests in CreatePackagePolicy produced empty inputRef keys (e.g. "nginx-") that Fleet rejects with "input not found". Refactor CreatePackagePolicy to accept policy template and data stream names instead of pre-loaded source manifests, and always read from the built package tree via builder.BuildPackagesDirectory. Both input-type and integration packages now go through the built bundle, removing the source/built inconsistency and ensuring the same resolved input keys Fleet sees. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…nifest reading This change adds the ReadBuiltPackageManifest function to encapsulate the logic for locating and reading the built package manifest. It simplifies the code in CreatePackagePolicy and related functions by reducing redundancy and improving clarity. The new function handles errors and returns both the built root path and the parsed manifest, ensuring consistent access to package data across the codebase.

…bstatus This commit introduces new sample event JSON files for the nginx composable access and stubstatus data streams. The access sample event includes log attributes and a message format, while the stubstatus sample event captures metrics related to NGINX connections. Additionally, updates to expected policy files and configuration files reflect changes in dataset naming conventions and minimum hit counts for assertions.

…able/input-name

…y templates This update enhances the input resolution process in the addPackagePolicy function by streamlining error handling and ensuring that the correct input type is assigned from the built package manifest. The changes include clearer error messages and checks for input availability, improving overall robustness and maintainability.

…able/input-name

mrodm · 2026-04-29T13:58:41Z

+# Prefer the elastic-package binary built in this repo (see Makefile `build`) so
+# composable install uses the same code as the checkout, not an older global install.
+if [[ -x "${REPO_ROOT}/elastic-package" ]]; then
+  PATH="${REPO_ROOT}:${PATH}"
+fi


This should not be needed. elastic-package is installed here

elastic-package/.buildkite/scripts/integration_tests.sh

Line 153 in 7ba5943

make install

And it should be available already in the PATH.

Here it is the installation in the Buildkite build: https://buildkite.com/elastic/elastic-package/builds/7852#019dd956-4795-49ef-b207-d1d2b25e1155/L436

mrodm · 2026-04-29T14:00:12Z

-stack_args=$(set +x; stack_version_args)
+# TODO: Remove --version below when composable tests pass on elastic-package's default stack
+# (Fleet/Kibana no longer require this snapshot).
+stack_args="--version 9.5.0-SNAPSHOT"


This should be tried with 9.4.0-SNAPSHOT before merging if possible.
I haven't checked if the required changes are available in the latest Snapshot of 9.4.0

mrodm · 2026-04-29T15:03:09Z

+		if builtRoot, builtPkg, berr := builder.ReadBuiltPackageManifest(manifestRoot); berr == nil {
+			if builtPT, berr := packages.SelectPolicyTemplateByName(builtPkg.PolicyTemplates, *polName); berr == nil {
+				inputName := config.Input
+				if inputName == "" {
+					if builtDS, berr := packages.ReadDataStreamManifestFromPackageRoot(builtRoot, dsMan.Name); berr == nil && len(builtDS.Streams) > 0 {
+						inputName = builtDS.Streams[0].Input
+					}
+				}


Errors from these functions are not validated. Should they be raised if any?

mrodm · 2026-04-30T08:52:38Z

+for bootstrap_name in "${COMPOSABLE_BOOTSTRAP_PKGS[@]}"; do
+  echo "--- Building bootstrap input package: ${COMPOSABLE_PACKAGES_PATH}/${bootstrap_name}"
+  # Bootstrap packages have no (or satisfied) requires.input; no registry yet.
+  # After build, artifacts land in build/packages/ for the stack local registry.
+  elastic-package build -C "${COMPOSABLE_PACKAGES_PATH}/${bootstrap_name}" -v
+done


Not required for this PR, but just thought that there could be added support for some kind of hooks for the packages tested under parallel or false positives could take advantage in case they need to run specific commands.

There could be some hooks:

before and after building the package

before and after installing the package

before and after testing the package

AFAIK there is no need for that now, so just commenting here this idea.

i am not sure i understand what you mean with hook here. you mean that before building a packagae we could have defined commands running? can you extend with an example?

In the main script (scripts/test-check-packages.sh), it could be added some code like:

for d in test/packages/${PACKAGE_TEST_TYPE}/${PACKAGE_UNDER_TEST}/; do echo "--- Checking package ${d}" if [ -f "$d/pre-check.sh" ]; then bash "$d/pre-check.sh" fi elastic-package check -C "$d" -v if [ -f "$d/post-check.sh" ]; then bash "$d/post-check.sh" fi done

echo "--- Run tests for package ${d}" if [ -f "$d/pre-test.sh" ]; then bash "$d/pre-test.sh" fi # Run all tests # defer-cleanup is set to a short period to verify that the option is available elastic-package test -C "$d" -v \ --report-format xUnit \ --report-output file \ --defer-cleanup 1s \ --test-coverage \ --coverage-format=generic if [ -f "$d/post-test.sh" ]; then bash "$d/post-test.sh" fi

Not sure if this could be helpful in the future, to try to allow customize even further the scenario for each package.

As I mentioned, just an idea that it came to my mind, no need to do it now.

teresaromero · 2026-04-30T09:48:03Z

test integrations

elastic-vault-github-plugin-prod · 2026-04-30T09:54:13Z

Created or updated PR in integrations repository to test this version. Check elastic/integrations#18579

…-SNAPSHOT and remove obsolete nginx_composable.stack_version file

…able/input-name

## Summary Found while working on composable packages elastic/elastic-package#3480 When an integration is bundled with inputs (composable packages) API reference should use the effective name instead of the input type. Effective name is introduced when two inputs share the same type, so they can be idetified. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) - [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. ### How to test Tested using the nginx_composable text fixture under [elastic-package ](elastic/elastic-package#3480) ### Screenshots Before <img width="1368" height="610" alt="Screenshot 2026-04-30 at 09 35 31" src="https://github.com/user-attachments/assets/e0ea3cba-ee2b-4ede-9b8d-30f413d336a2" /> After <img width="1134" height="738" alt="Screenshot 2026-05-04 at 14 45 42" src="https://github.com/user-attachments/assets/7aecde20-4b0e-4384-8a61-bb1ea0c40d34" />

jsoriano

Tested and seems to work great, thanks!

I have a couple of concerns on the code:

There is some complexity on deciding when the source or the built manifests need to be used. In most testers I think we should always use built packages, and thus we can assume that we have the build manifests available.
[Nit] For the qualifier name/type we use "effective input name" in Kibana, and "input ref" here. If possible it would be great to use the same terms to avoid confusion.

jsoriano · 2026-05-05T09:52:51Z

+	if r.testFolder.DataStream == "" {
+		return false
+	}
+	builtRoot, builtPkg, err := builder.ReadBuiltPackageManifest(r.packageRoot)


This method already receives a manifest. Do callers need to be able to work both with source and built manifests?
If this is always working with built packages callers could use always built manifests so we don't need to read it again here.

this is not trivial change, for static tests we need both package source and built.

It would be good to check why static tests need both, we can leave this for a future refactor.

jsoriano · 2026-05-05T10:02:39Z

+
+	// Always resolve against the built tree so that RequiredInputsResolver has already
+	// materialized package: references into concrete input types.
+	builtRoot, builtPkg, err := builder.ReadBuiltPackageManifest(packageRoot)


We are reading and using the built package manifest in several places. I would prefer to read it only once and then pass it.
My main concern is not about reusing the read manifest, but about having to decide every time what manifest should be used.

As this is a system tester, we can probably use always the built manifest, as a built package should be available.

i think this change is related to a test structure refactor. we needed to introduced the built bundle to work with composables, can we aford this debt and address the refactor as a followup? i can open an issue for it

Definitely, we can do this in a follow up.

jsoriano · 2026-05-05T10:09:43Z

 	ts.Check(decoratedWith("finding policy template", err))

-	policy, dsType, dsDataset, err := system.CreatePackagePolicy(installed.testingPolicy, pkgMan, templ, dsMan, config.Input, config.Vars, config.DataStream.Vars, installed.testingPolicy.Namespace, manifestRoot)
+	// For composable integration packages the source manifest has unresolved "package:" references,


We should probably test always with built packages to avoid this complexity.

same as here #3480 (comment)

Ok, let's do it in a follow up.

mrodm

LGTM!
I've also tested locally and the nginx_composable built package looks good too 💪

mrodm · 2026-05-05T10:40:59Z

+	builtPkg, err := packages.ReadPackageManifestFromPackageRoot(builtRoot)
+	if err != nil {
+		return kibana.PackagePolicy{}, "", "", fmt.Errorf("reading built package manifest at %s: %w", builtRoot, err)
+	}


When the package is of type "integration" this call would produced the same builtPkg value as in https://github.com/elastic/elastic-package/pull/3480/changes#diff-0bdd696fb9abd5e4aa12a3bab634cbac31ec1a1349b3a61e8a784a6bdeb6e7d8R2272-R2275

Would it be valid to set as parameter builtPkg instead of builtRoot? Would it be equivalent ?

mrodm · 2026-05-05T10:44:22Z

 			}

-			upsertKey(streamNode, "input", strVal(info.identifier))
+			upsertKey(streamNode, "input", strVal(streamInputRefs[stream.Package]))


Should it be ensured that stream.Package is present in streamInputRefs to return some error before doing this call ? As it has been done for infoByPkg at line 195.

… (#267703) # Backport This will backport the following commits from `main` to `9.4`: - [Fix composable inputs on API reference integration docs (#267472)](#267472)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  Co-authored-by: Tere <teresa.romero@elastic.co>

Updated the input resolution logic in BuildIntegrationPackagePolicy and FindInput functions to utilize effective names instead of references. This change enhances clarity and consistency in identifying inputs across data stream manifests. Additionally, adjusted related tests to reflect the new naming convention.

Updated the inputPkgInfo struct to eliminate the pkgName field, simplifying the data structure used for input package metadata. Adjusted related test cases to align with this change, ensuring consistency in input handling across the codebase.

Refactored the inputPkgInfo structure and related functions to replace the identifier field with effectiveName, enhancing clarity in input package metadata. Adjusted test cases to ensure consistency with the new naming convention across the codebase.

Updated the inputPkgInfo structure to inputPolicyTemplateInfo, replacing effectiveName with input for clarity. Adjusted related functions and tests to ensure consistency in input resolution across policy templates, enhancing the overall structure and readability of the codebase.

Updated the comments in the buildStreamInputRefs function to provide a clearer explanation of how input references are constructed for required input packages. The new documentation outlines the handling of duplicate input types within policy templates and the significance of stable qualifiers, improving understanding of the input resolution process.

…putTypesToDataStreamManifests function Updated the applyInputTypesToDataStreamManifests function to include a check for the existence of stream input references. If a reference is not found for a given package, an informative error message is returned, enhancing the robustness of the input handling process.

…lt to improve data stream handling Updated the CreatePackagePolicy function to read data stream manifests and all data streams directly from the built package root. Refactored the buildIntegrationPackagePolicyFromBuilt function to accept the built package manifest, data stream manifest, policy template, and all data streams as parameters, enhancing clarity and error handling in policy creation.

jsoriano

👍 ready to go, and we can address the requested refactors in follow ups.

teresaromero · 2026-05-07T07:56:27Z

Opening followup issue to address test refactor #3530 ;

teresaromero · 2026-05-07T07:56:49Z

test integrations

elastic-vault-github-plugin-prod · 2026-05-07T08:03:43Z

Created or updated PR in integrations repository to test this version. Check elastic/integrations#18579

elasticmachine · 2026-05-07T08:36:06Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: cbe6b1c

Failed CI Steps

History

💚 Build #7892 succeeded b2eff03
💛 Build #7874 was flaky f3d6525
💔 Build #7872 failed ccc9dee
💛 Build #7861 was flaky 5c807ec

teresaromero · 2026-05-07T09:32:19Z

test integrations

elastic-vault-github-plugin-prod · 2026-05-07T09:37:56Z

Created or updated PR in integrations repository to test this version. Check elastic/integrations#18579

mrodm

🚀

teresaromero and others added 7 commits April 20, 2026 14:31

Merge branch 'main' of github.com:elastic/elastic-package into compos…

c27b5aa

…able/input-name

Merge branch 'main' of github.com:elastic/elastic-package into compos…

734716a

…able/input-name

teresaromero changed the title ~~[Draft] Composable packages: input name qualifiers and stream input refs (package-spec #1135)~~ Composable packages: input name qualifiers and stream input refs Apr 22, 2026

teresaromero added 2 commits April 22, 2026 10:28

teresaromero marked this pull request as ready for review April 22, 2026 09:33

teresaromero requested a review from a team April 22, 2026 09:35

elastic-vault-github-plugin-prod Bot mentioned this pull request Apr 22, 2026

Test elastic-package#3480 - DO NOT MERGE elastic/integrations#18579

Draft

mrodm reviewed Apr 22, 2026

View reviewed changes

jsoriano and others added 14 commits April 22, 2026 13:10

Add composable test package for nginx

1a62bba

Enhance Nginx composable data stream configuration by adding variable…

2a34f0c

… definitions for access logs and updating policy files to include data stream structure. Introduced expected output files for both access and stubstatus data streams to improve testing coverage.

refactor: remove FindInputByType method from PolicyTemplate

492bdcb

Eliminated the FindInputByType method from the PolicyTemplate struct to streamline the codebase. This change simplifies the input retrieval process, as the method was not utilized in the current implementation.

Merge branch 'main' of github.com:elastic/elastic-package into compos…

648e22d

…able/input-name

Merge branch 'main' of github.com:elastic/elastic-package into compos…

b8f6ccb

…able/input-name

chore: update nginx composable stack version to 9.4.0-SNAPSHOT

86fa6b5

Merge branch 'main' of github.com:elastic/elastic-package into compos…

fe65c91

…able/input-name

teresaromero added 2 commits April 30, 2026 10:25

Merge branch 'main' of github.com:elastic/elastic-package into compos…

5c807ec

…able/input-name

mrodm reviewed Apr 30, 2026

View reviewed changes

teresaromero added 3 commits May 4, 2026 09:42

Update test-composable-packages.sh to use Elastic stack version 9.4.0…

64d7f53

…-SNAPSHOT and remove obsolete nginx_composable.stack_version file

Merge branch 'main' of github.com:elastic/elastic-package into compos…

ccc9dee

…able/input-name

Add nginx_composable.stack_version file with version 9.4.0-SNAPSHOT

f3d6525

teresaromero mentioned this pull request May 4, 2026

Fix composable inputs on API reference integration docs elastic/kibana#267472

Merged

8 tasks

jsoriano mentioned this pull request May 5, 2026

Nginx composable package #3432

Closed

jsoriano reviewed May 5, 2026

View reviewed changes

mrodm reviewed May 5, 2026

View reviewed changes

teresaromero added 7 commits May 5, 2026 15:37

jsoriano approved these changes May 6, 2026

View reviewed changes

mrodm approved these changes May 7, 2026

View reviewed changes

teresaromero merged commit 2ebd2bc into elastic:main May 7, 2026
4 checks passed

Conversation

teresaromero commented Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why

What changed

How to verify

Related

Depends on

Uh oh!

teresaromero commented Apr 22, 2026

Uh oh!

elastic-vault-github-plugin-prod Bot commented Apr 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

teresaromero commented Apr 30, 2026

Uh oh!

elastic-vault-github-plugin-prod Bot commented Apr 30, 2026

Uh oh!

jsoriano left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mrodm left a comment

Choose a reason for hiding this comment

teresaromero commented Apr 20, 2026 •

edited

Loading

elasticmachine commented May 7, 2026 •

edited

Loading