I like the idea behind this, but I'm not 100% convinced that we can do this without dropping the flexibility that we get from OpenSLO vs the other formats you mention.

We love Sloth and are using it in production with our clients, and the lack of support for certain parts of OpenSLO has indeed meant that we have gone with the Sloth native format.

I'm wondering if there's a compromise to be had here by retaining the dataSource but moving it down a level and making it optional so we get something like this:

apiVersion: openslo/v1
kind: SLO
metadata:
  name: shorter-slo
spec:
  indicator:
    spec:
      ratioMetric:
        good:
            query: results{code="good"}
            dataSource: prometheus  # Optional Field 
        total:
            query: results{}
            dataSource: prometheus  # Optional Field
  budgetingMethod: Timeslices
  targetPercent: 99.9
  timeSliceTarget: 0.9
  timeSliceWindow: 5m

I only suggest this because I have a feeling there may be times where our larger customers may want an SLI that pulls the "good" events from one source and the "total" events from another. Granted, we don't actually have this use-case at the moment, but we do have systems where "success/failure" is logged to a file on disk and yet details of the actual execution of the task are stored in a SQL database.

In this event, we could do something like:

apiVersion: openslo/v1
kind: SLO
metadata:
  name: shorter-slo
spec:
  indicator:
    spec:
      ratioMetric:
        good:
            query: SELECT COUNT(id) FROM logs WHERE success == "1" AND system_id == "our_platform";
            dataSource: SQLDB 
        total:
            query: count_over_time({system_id="our_platform"}[1h])
            dataSource: loki
  budgetingMethod: Timeslices
  targetPercent: 99.9
  timeSliceTarget: 0.9
  timeSliceWindow: 5m

Sloth, Pyrra, and other tools could then just ignore the dataSource for each query because they are focused on a single data storage layer, whereas tools such as Oslo or SloGen would observe the dataSource field for each query and act accordingly?

Indents in both your yaml examples are inconsistent, it makes it hard to follow.

I like your suggestion, but at the same time the DataSource/metricSource bits of the spec are sufficiently unclear that I'm not sure how they're supposed to be used and therefore how to make changes compatible with them.

I've added a separate short issue that implements a version of what you've proposed in #162

Indents in both your yaml examples are inconsistent, it makes it hard to follow.

Odd, it was a cut/paste, I'll try and fix it shortly.

I like your suggestion, but at the same time the DataSource/metricSource bits of the spec are sufficiently unclear that I'm not sure how they're supposed to be used and therefore how to make changes compatible with them.

I've just seen your comments on #162 - I'm not opposed to that approach by any means, definitely feels like a discrepancy there, now I'm wondering whether we need #162 or whether it can just be pulled in to this issue?

Both Sloth and Pyrra support only Prometheus which makes things much easier. OpenSLO aims to be flexible enough to support every data source. As described in #107, different data sources have different idiosyncracies in defining how to pull data from them. I think we're not able to come up with a spec that will be universal, so we made a decision to leave it to implementation. Being able to reference arbitrarily chosen data sources in different queries as a part of one SLO is needed to be able to implement powerful composite SLOs as described in #142.

I favor simplicity, but I would rather avoid hurting flexibility because we want others to adopt OpenSLO and they may have different needs and we used to try to address them. I think it's very good to have a broader discussion and improve the current state, but we have to be cautious

One approach, which @proffalken and I discussed at Monitorama, to help with simplification is a means of defining an SLO with a cucumber like syntax. All the details needed for an OpenSLO compliant document are then generated from the syntax.

Granted, it would be very limiting as it would not be possible to have a detailed cucumber like syntax without it also becoming overly complex, but it could be used for the "simple" SLO cases to reduce what needs to be defined.

It's a really interesting idea @kenfinnigan & @proffalken, we need to discuss this further. I've seen #146. It should help with SLO adoption and cross-department understanding in bigger organizations that may not be technological companies. It may give them simple guidelines/templates on how to define SLOs for new services, user journeys, etc. without bothering about every detail

@programmer04 it was inspired by Sophia's talk at Monitorama.

I still think a good "first step" is to move the datasource into the metric so tools like pyrra/sloth can just ignore it whilst others make use of it, but my bigger concern here is that in the pursuit of something more simplistic the wider spec and process of getting an easily adopted toolchain is neglected.

I'm in favour of this PR (And of simplification in general), but I'd rather see the community focus on Olso / SloGen and getting them working with a larger number of platforms as a priority so we have an ecosystem that can easily be deployed to customers.

I'm about to head out for a week of PTO, so can't really catch up on the discussions here (though I'll do that before the next call), but it just occurred to me that timeWindow also suffers from the oddity of being a single object list. The really concise version could be just spec.window: 28d.

Per discussion of this issue during yesterday's community call, I've split all proposals into three separate issues, so that they can be worked on separately, and updated this issue to match.

Since the 3 issues that you split from this one are closed @mmazur I'm closing this main issue :)