Simplified Syntax: move away from the single-item `.timeWindow[]` list

[mmazur]

Problem to solve

The spec.timeWindow list of the SLO object accepts only a single item. This means time window options could be provided without using the timeWindow list with no loss of functionality.

Proposal

Following changes to the spec are proposed:

1. The timeWindow[] way of doing things is marked as optional, deprecated and to be supported for backwards compatibility only.
2. These additions to SLO.spec become the preferred way of defining time windows:

   kind: SLO
   spec:
     window: duration-shorthand # assumed a rolling time window unless `calendar` is provided
     calendar: # if provided, the time window is to be treated as calendar-aligned; otherwise defaults to a rolling time window
       startTime: 2020-01-21 12:30:00
       timeZone: Europe/Brzyskorzystewko
   

Further details

This is one of the cases implementing suggestions from #160.

[programmer04]

Why do you suggest making timeWindow[] deprecated? There are real-world examples of use cases where you want to have defined multiple time windows per SLO. For example, a calendar-aligned window that reflects SLA and a shorter rolling window that is an internal indicator for teams how well they deploy without downtimes, etc.

Maybe we should be more descriptive in our spec about possible use cases of multiple time windows. This is the broader discussion - do we want to include such things in the main spec or in some other document?

[mmazur]

Insufficient support for these changes, closing the issue.