oxidecomputer / oxidecomputer/omicron

Simplify oxql responses

Open
#9,324 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
572
Forks
97
Avg merge
2d 12h
Merged PRs (30d)
96

Description

Here's an excerpt of the response from the timeseries query endpoint:

            "values": [
              {
                "metric_type": "delta",
                "values": {
                  "type": "integer",
                  "values": [
                    118824099830713,
                    4957551326,
                    4966427295,
                    4956182957,
                    4958472616
                  ]
                }
              }
            ]

I think this can be simpler in a few ways:

  • The metric and value types are properties of the metric, so I think we can hoist them to the level of the table, rather than nesting them and repeating them for each timeseries.
  • We have a top-level values array, which includes a values map, which includes another values array. Can we either elide some of this nesting (if we move metric_type and type to a higher level, this structure would only include fields named "values"), or pick more meaningful names? And out of curiosity, will the top-level values array ever have more than one element?

Probably questions for @bnaecker.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the timeseries query endpoint and the response example in this issue. Resolve whether metric and value types can move to table level, whether the nested values fields should be renamed or removed, and whether the top-level array can contain multiple elements. Done means the response shape and its intended cardinality are agreed and documented for implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
api
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.