Add SLO assets to the package spec

[mgiota]

Fixes https://github.com/elastic/observability-dev/issues/3602

✔️ Acceptance criteria

• add SLO assets to the kibana spec
• add slo test examples

[mgiota]

@jsoriano I have a draft PR here that adds the SLO assets to the kibana spec. I plan to add some unit tests in the PR, but here's what CI is complaining about at the moment:

could not load spec for "integration/kibana/spec.yml": could not parse folder specification file: yaml

I have a couple of questions:

• Could you further assist why I am getting this error? I gave the name slo to the new folder. Shall I specify somewhere else what is considered a valid folder name?
• Where shall I write my unit tests?
• I was reading the Contributing guide. Shall I create a new Change Proposal issue?

[mgiota]

CI is complaining

It turns out it was an indentation issue, which was fixed in this commit

Where shall I write my unit tests?

I added following slo examples:

• test/packages/good/kibana/slo/good-slo-abc-1.json
• test/packages/good_v2/kibana/slo/good_v2-slo-abc-1.json
• test/packages/good_v3/kibana/slo/good_v3-slo-abc-1.json

Shall I create a new Change Proposal issue?

I didn't create any new issue, cause I found this one.

[muthu-mps]

@mgiota - Do we need to load the SLO's inside the Kibana directory? Are there any guideline on defining SLO's.

[mgiota]

@muthu-mps I added it here as per @jsoriano 's recommendation in the past. Here's the public SLO API and the SLO Elastic documentation

In this PR I added some examples of SLO creation.

[mgiota]

In this commit I updated the README file to include the SLO assets. As you can see there are many other Kibana assets in the list as for example rules, ml modules, dashboards and I guess it makes sense to add slo here as well.

[mgiota]

@jsoriano I open up this PR for review. Let me know what other changes I might need to do that I am not aware of. Thanks!

[mgiota]

test integrations

[elasticmachine]

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

[mgiota]

I was following the Contributing guide and I commented test integrations in this PR, but I am not sure why the auto generated PR is failing. Could you help me out here?

[jsoriano]

Change LGTM, but we have to decide on what version we would release it, and add a changelog entry.

To decide what version to use, the main question would be regarding the level of support in Kibana. If a package using this feature requires changes in Kibana to work properly, then we should add the change into 3.3.0-next, if not, we can add it in 3.2.1-next.

We release almost everything on patch versions, we use minors for changes that require also changes in Kibana, and majors for breaking or significant changes in the spec itself.

[jsoriano]

I am not sure why the auto generated PR is failing. Could you help me out here?

The failures there are not related to this change, no worries 🙂 aws package uses to be flaky, and azure_blob_storage has a known issue.

[mgiota]

To decide what version to use, the main question would be regarding the level of support in Kibana. If a package using this feature requires changes in Kibana to work properly

As far as I understand there will be some changes in the Fleet module in kibana to make the whole integration work. So I guess we should add the change into 3.3.0-next.

add a changelog entry

I found a couple of changelog files. Where exactly should we add the new SLO asset support? Or is the change you recommnded in the spec file enough?

[mgiota]

@jsoriano Now I am getting some validation errors:

found 1 validation error:
1. item [slo] is not allowed in folder [../../../../test/packages/good_v2/kibana]        	            	   

Do I need to specify the new slo item anywhere else? The tests started failing after I committed the change with the patch version. So I guess I am missing something else as well.

[jsoriano]

Do I need to specify the new slo item anywhere else? The tests started failing after I committed the change with the patch version. So I guess I am missing something else as well.

The problem is that the good package uses an old version of the spec, and packages with SLOs will need to have at least a format_version equal or greater than 3.3.0.

I would recommend to move the test files you added to the good_v3 package and increase its format_version to 3.3.0.

You can run these tests locally for faster feedback, with go test ./... from the root directory of the repository.

[jsoriano]

Thanks!

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 1dc5d83

History

• 💔 Build #723 failed df71b57
• 💔 Build #722 failed 83aaf2c
• 💔 Build #721 failed 27986b1
• 💔 Build #720 failed e8240d7
• 💔 Build #719 failed ff88db1
• 💚 Build #718 succeeded d78edf9

[muthu-mps]

@mgiota , @jsoriano - Just FYI, The directory structure we follow for the integrations to include SLO's and the general guidelines around using the ID's as name of the json file is still in discussion. We can continue those discussions in the issue. This may evolve going forward.

[mgiota]

@jsoriano Looks like I am not authorized to merge this PR. Could you either merge the PR or grant me access to merge it?

[ruflin]

@mgiota Thank you for making this happen!!!