RFE: Build reporting capability in the QUADS

[natashba]

We need to add reporting capability into quads so it can be exported and presented. We would like to see usage and allocation history in both Scale lab and ALIAS lab such as: Allocation % over past quarters, FY to Date Number of requests satisfied in past quarter, FY to Date Number of strategic initiative requests Median number of server and storage capacity Backlog lead time Average configuration & turn around time Number of request not meeting the SLO Number of Extension request Number of customer related requests

[sadsfae]

Thanks for filing this, some of this exact data will not be available to QUADS, comments in-line to address:

We need to add reporting capability into quads so it can be exported and presented. We would like to see usage and allocation history in both Scale lab and ALIAS lab such as: Allocation % over past quarters, FY to Date

Located in QUADS history.

Number of requests satisfied in past quarter, FY to Date

Located in QUADS history.

Number of strategic initiative requests

Strategic is not empirical data we would record, instead the best we can do is pattern match based on assignment titles and/or scrape RT information and correlate this. Humans would still need to peruse the product/portfolio and apply whatever is strategic at that time.

Median number of server and storage capacity

Available via --ls-available functionality in quads-cli

Backlog lead time

This data is not in QUADS, it would need to be pulled in from RT ticketing - comparing the delta of new requests across when their status label was updated (pending review, under review, approved, scheduled, in-progress). I would say that we need to automate applying RT category labels based on the request and subsequent assignment status - we're not consistent enough doing this on our own for this metric to be 100% accurate.

Average configuration & turn around time

What constitutes configuration and turn-around time? Do you mean time for allocation/provisioning/validation and hand-off of systems?

If this is what you mean a bunch of things happen, and each system of each new assignment goes through the following:

• Systems are reprovisioned
• Network switch changes are made
• Out-of-band / IPMI credentials are changed
• Foreman RBAC changes occur
• Foreman host parameters are modified
• Systems validation occurs
• Network validation occurs

The total time for processing all of this is probably what matters, but to record this we'll probably need to implement additional mongo collection data on a per-host basis, as well as a top-level one at the cloud level to record overall timeframe to deployment (finish time).

Number of request not meeting the SLO

What is an SLO? Did you mean SLA? If so that's easy enough to determine, we aim for assignments to be available by 9:30am EDT the following Monday that they are scheduled - so exactly 15hours from the scheduled start date. Determining criteria met here would just involve comparing the start time to when the assignment is released to see if it exceeds this timeframe or not.

Number of Extension request

This is not QUADS data, it would need to be pulled in from scheduling spreadsheets and cross-referenced with the RT ticket system.

Number of customer related requests

This is not QUADS data, it would need to be pulled in from the RT ticketing system. Further, we'd probably want a definitive checkbox or tick to indicate this is for a customer rather than rely on scraping free-form fields from the request.

[sadsfae]

For reference, here is the MongoDB ERD diagram of QUADS 1.1+

We'll need to discuss / design / architect both how this would look as well as a bare-minimum set of requirements and what other source(s) might be in play.

I think at a minimum we would want:

• set of quads-cli argparse parameters for general time-based reporting things like # of requests, requesters, run times for environments, # of systems per, resource availability %, breakdown of free systems, breakdown of used system types.

e.g. quads-cli --report --start-date | --stop-date | --output with a few output types that make sense (csv, sql, txt)

• some type of cumulative reporting page, automated / auto-generated like our visuals or assignments/systems wiki.

• some kind of monthly or interval-based reporting process / cron that keeps historical data for review - possibly pulling in from other sources as needed (or export from QUADS reporting and generated somewhere else entirely.

[sadsfae]

We've moved up the first implementation of this, we're moving from RT to JIRA internally so we will wait for that to be completed and get a better understanding of the JIRA API before we target JIRA/request information inclusion.

For now these are the two major features that the first iteration of reporting will consume more or less.

[sadsfae]

This is implemented.