-
Notifications
You must be signed in to change notification settings - Fork 9
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
Create design-update.md #40
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: Oscar Esteban <[email protected]>
|
||
|
||
## Message packets | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Try TCP/Restful first, resort to UDP if communication fails |
- ETA (progress bar or such, using previously acquired stats from other users) | ||
|
||
## Wishlist | ||
- use a more generic logging tool as the backend (like prometheus) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- use a more generic logging tool as the backend (like prometheus) | |
- identification logic to establish user/session constructs that allow: 1) defining a "unique users" concept; 2) defining "exit points" where sessions are aggregated (i.e., 90% of the processes ended on this particular error). | |
- use a more generic logging tool as the backend (like prometheus) |
- Relevant options | ||
- "Session" information | ||
- "User" information | ||
- (possibly) Elapsed time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- (possibly) Elapsed time | |
- (possibly) Input dataset hash - so that we could identify open data executions (if the dataset is run unaltered). | |
- (possibly) Elapsed time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a great starting point - once this is somewhat set, we should set up a call and discuss next steps
i would like to avoid. | ||
- make querying, accessing, and doing analytic plots | ||
- spin up your own backend on heroku/some such | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- revisit backend DB choice (mongo/sqlite/redis) |
(even though not advertised). if messages become arbitrary, we may need | ||
registration/auth tokens. brings up a whole different level of complexity that | ||
i would like to avoid. | ||
- make querying, accessing, and doing analytic plots |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to making the data acquired more usable, just need to be mindful of large server load increase
Here's an ongoing draft: https://github.com/mgxd/fastapi-telemetry A few design notes on the backend:
|
Design doc for next version of the etelemetry service