Fixed QFlappingShift date boundary and summing bugs

[abyrne55]

There's a bug in the definition of _query() for the Question subclass QFlappingShift (a.k.a. "Which alerts fire more than once per on-call shift (in the same cluster)?") where date boundaries (since and until) were not being considered, leading to increasingly-large results for that query. This PR fixes that bug by adding an SQLAlchemy filter clause along the lines of:

WHERE alert.creation_time > time_window_start && alert.creation_time < time_window_end

There's also an undocumented bug in the above-mentioned method that caused flap counts to not be summed across days, leading to duplicate entries in the answer table. This PR fixes this by converting the original query into a subquery, and then returning a new query that sums across the subquery.

This PR addresses bug OSD-11288 (date boundaries).

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abyrne55

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [abyrne55]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@abyrne55: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[boranx]

/hold
/lgtm

Looks good, (personal thoughts) I think in general it's better to put filtering logic into code and let db layer just query the data
unhold upon your availability

[boranx]

/lgtm

[abyrne55]

(personal thoughts) I think in general it's better to put filtering logic into code and let db layer just query the data

@boranx I genuinely appreciate the feedback. I'm going to unhold this PR and continue the conversation with you off-GitHub, as changing to a code-does-the-filtering approach would require a larger refactor, IMO.

[abyrne55]

/unhold