Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: Build reporting capability in the QUADS #271

Open
natashba opened this issue Jul 8, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@natashba
Copy link

commented Jul 8, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

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

quads-erd-mongo

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 sadsfae changed the title Build reporting capability in the QUADS RFE: Build reporting capability in the QUADS Jul 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.