Separation of SLO and SLI

[ian-bartholomew]

In order to promote separation of concern between the SLOs and the SLIs, we should separate out the two. This has the added benefit of portability as well as allowing for better access control for the files. In addition, it keeps the SLO definition separate and independent of the data sources

[its02003]

@ian-bartholomew If we decide to do that, I am OK with closing out some of my issues and focusing the debate here...

This overlaps with #38 and #29

[geototti21]

Hey @ian-bartholomew @its02003. I find the SLO /SLI separation also useful. I can think of the following use-case that this separation will make SLO/SLI separation easier.

Service A Repository

• SLO.yaml file that holds SLOs for the service + metadata (dashboard links, etc.) and optional a reference to SLIs used ( some kind of unique identifier needed here, that should be the same in SLI.yaml), to avoid conflicts we can prefix it with repo name. This file know nothing about data sources, just the SLO spec.
• SLI.yaml files that hold all the data source related information and know details about data source/implementation.
• PS: for anyone using backstage or similar having these files next to the code of the service will make life easier around management and visibility.

Use Cases

• A harvest tool for SLO.yaml files that can scan the organisation and automatically create dashboards, alerts
• A harvest too for SLI.yaml files that can scan the organisation and register new SLIs and data sources.

Both of the above tools serve a completely different purpose and possible use different tech/tooling to generate the outputs needed for their use case. We can achieve the same by having SLO/SLI in the same file but it doesn't help with the separation of concerns when it comes to tooling.

[mmazur]

This as an option is a great idea. But this needs to happen as an alternative to the single–file definition. The spec makes defining SLOs quite verbose already and increasing minimal required verbosity to achieve something should be an anti–pattern.

In python the simplest working program is a single line print("Hello world"), yet that does not prevent anybody from writing a full–fledged object oriented beast of a codebase. That's the level of syntax flexibility everybody should be aiming for.

[kenfinnigan]

@ian-bartholomew can you confirm if the intention was separating SLI into a separate kind as opposed to being inside SLO?

That's the way I interpreted it, but I want to confirm

[ian-bartholomew]

@kenfinnigan yeah, the intention is to make the SLI a separate kind, correct. Thanks!

[kenfinnigan]

@kenfinnigan yeah, the intention is to make the SLI a separate kind, correct. Thanks!

Thanks for confirming.

In this case, I think separation of SLIs and SLOs into separate files is orthogonal to separating the definition. Once they have separate definitions, whether it's all in one file or across several would not be a concern of the spec, for me.

[proffalken]

This makes sense to me - the number of files doesn't matter, but the ability to distinguish between an SLI and an SLO does.

More than happy to support this in prep for v1, might be worth adding a note somewhere along the lines of "If you want to split them into different files, that's up to you, but we're not going to force you either way as part of the spec"? Or does that make things more complex?

[ian-bartholomew]

"If you want to split them into different files, that's up to you, but we're not going to force you either way as part of the spec"

Thats my preference, leaving it up to the user to define those. so like @kenfinnigan said, I wouldn't make an opinion about it in the spec

[kenfinnigan]

With the merging of @soasme's PR, this can be resolved