Add date and time in utilization sparklines

[leistnerova]

Utilization sparkline contains current value but not date and time and so it is not obvious what interval is used and e.g. what time was the highest peak to work further with the information.

[sjd78]

The historic statistics from the REST API do not include timestamps with the data points. So apart from those datapoints somehow being tied to the current date/time (the first data point being the closest half minute past now), there is no way to put date and time stamps on the data points.

Here is an example of the cpu usage history for a VM as returned by the API:

{
  "kind": "gauge",
  "type": "decimal",
  "unit": "percent",
  "values": {
    "value": [
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 4
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      },
      {
        "datum": 3
      }
    ]
  },
  "name": "cpu.usage.history",
  "description": "List of CPU usage history, sorted by date from newest to oldest, at intervals of 30 seconds",
  "id": "bde6d1ed-e07b-3aa1-bfc4-463990f5921a"
}

[leistnerova]

The API result looks strange, 'datum' is czech word for date. I will check that with some developer.

[bond95]

The API result looks strange, 'datum' is czech word for date. I will check that with some developer.

Datum is singular for data. https://www.gingersoftware.com/english-online/spelling-book/confusing-words/data-datum

[sjd78]

The API result looks strange, 'datum' is czech word for date. I will check that with some developer.

Datum is singular for data.

(from the linguist in me) In Latin for sure, in English "datum" is understood as a single piece of data depending on the specific technical area you're working in. English is strange even for native speakers.

Here is the docs for the statistic type that is from above: http://ovirt.github.io/ovirt-engine-api-model/4.3/#types/statistic

[leistnerova]

Ah :) thanks guys for explanation.

[gregsheremeta]

setting blocked -- would require an API enhancement

[michalskrivanek]

@gregsheremeta those are fixed intervals, we can say "T-x", estimate would be enough

[sjd78]

those are fixed intervals, we can say "T-x", estimate would be enough

While they are fixed (every 30 seconds), are they always current? The only point in time to count backwards from is the time the data is fetched. I have not tried to drill in to the engine code to figure out that answer. For example, if I stop the VM for awhile and then restart it, what would be the time diffs from now for the historic data set?

[gregsheremeta]

For example, if I stop the VM for awhile and then restart it, what would be the time diffs from now for the historic data set?

Yeah, I think that ruins being able to use this. As we discussed in this morning's meeting, seems like we actually need timestamps on the data points.

@jelkosz @michalskrivanek opinions?

[sgratch]

Due to a capacity reason, we won't invest on adding a timestamp on the data points.
We can rather consider adding a tooltip for a general info regarding maximum time range e.g. the information for the last 24 hours...