-
Notifications
You must be signed in to change notification settings - Fork 81
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
Test Kitchen should provide telemetry #270
Conversation
Signed-off-by: Thom May <thom@chef.io>
Signed-off-by: Thom May <thom@chef.io>
When and how often is the payload being uploaded? |
To copy over comments from meeting: should dive into implementation details at least a bit on how the actual upload will work, and note that the box name or image name for the driver will only be collected if it's a "standard image" (i.e. not something made by the user where the name might reveal info). |
new/kitchen_telemetry.md
Outdated
envisage that a single client library will be built for all chef | ||
projects, and Kitchen will consume that to send events. That library | ||
would ensure events are sent in a non-blocking manner, and would deal | ||
with retries, session handling and opt-out. |
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.
How would you deal with a standalone client, which may never be connected to the internet? Is there a throttling or exponential backoff process which would cause the system to never try reporting again even though the user may not have configured the anonymous data collection configuration file (i.e. PR #269) to prevent data collection? Please have a way to keep this in check and even disabled automatically in unexpected circumstances.
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.
Yes, the client will do exponential back off, and will probably only do a relatively small number of retries. I think it's reasonable to expect that once a client detects it can't connect to the stats endpoint it'll stop trying for the rest of the lifetime of that process, but I don't think we'd disable the system from ever trying again; that's the user's responsibility.
Echoing my comments from #269 - I emphatically urge this not to be implemented as opt out (opt in is acceptable to me). Test Kitchen is a core piece of my workflow today, but moving to an opt out approach for this will cause me to seek immediate replacements. |
This is a complete event as received by the analytics system:
The current branches of this work are at https://github.com/test-kitchen/kitchen-vagrant/compare/tm/telemetry ; https://github.com/test-kitchen/test-kitchen/compare/tm/telemetry to give examples of what an implementation might look at. |
Approved by popular vote @chef/rfc-editors |
Signed-off-by: Adam Leff <adam@leff.co>
Accepting RFC 095 |
No description provided.