-
Notifications
You must be signed in to change notification settings - Fork 7
Server: Fedora CoreOS Pinger Backend Design #33
Comments
I'm leaving here a single comment, but this covers all of #30, #32 and #33. I'd rather suggest that we start the other way around (i.e. from the intended usecases for this data), until we finally reach the format on-wire, the backend implementation and the database. That is, we should ask ourselves and answer in order:
|
@zonggen as you updated the ticket in the meanwhile, let me map my comment to your example. Are we interested in answering things like "how many GCP nodes actively reported in the last two weeks" or "how many openstack nodes reported yesterday with a non-latest OS version"? |
To summarize my understanding, our main purpose of this project is to know (from coreos/fedora-coreos-tracker#86 (comment))
Since different information is gathered under the flag For database schema, two collections can be created: We could use json format when sending the data (or any other format with key/value storage) and make a HTTP POST request to server. |
I think the scale of flexibility of answering such questions depends on how organized/well-designed our database is. For example, "how many GCP nodes actively reported in the last two weeks" can be retrieved from our database by "sum(platform_id='gcp' where d1 <= date <= d2) " and "how many openstack nodes reported yesterday with a non-latest OS version" by "sum(platform_id='openstack' where date=d and os_release != latest_ver)". |
One question for the backend would be, how are we going to make sense of the data under the flag |
After sending the data, we need an endpoint to collect the data sent from client side.
Current plan is to run a simple HTTP server inside a container and aggregate the data sent from clients according to different time intervals (daily vs. monthly).
After receiving the data, the server would store the information depending on the information types (e.g. platform_id, os_version etc.) and count the number of instances that has this information. A report script that summarizes this information would be helpful too.
An example would be:
The text was updated successfully, but these errors were encountered: