kubernetes / steering

The Kubernetes Steering Committee
Apache License 2.0
86 stars 61 forks source link

Collect usage metrics for minikube #259

Closed medyagh closed 10 months ago

medyagh commented 2 years ago

Problem Statement

Per conversation with @mrbobbytables creating this issue.

Minikube has a lot of commands, sub commands and features/drivers, container runtimes and features on a matrix of OS and CPU Architectures, but unfortunately we do not have any metrics that tells us what drivers/container runtime or which minikube commands are being used most by the users, which makes it hard to decide what features or drivers or runtimes to invest or which ones to deprecate.

Proposed Solution

Collect usage metrics for basics commands of minikube on which commands get invoked and which commands have highest non-zero exit codes, and also other metrics such as operating system and CPU architecture and so on.

Cost

N/A

Open Questions

Next Steps

Other Considerations, Notes, or References

BenTheElder commented 1 year ago

Discussed at Today's Steering Meeting.

Immediate Action Items:

/assign

Possible related prior art within the project:

medyagh commented 1 year ago
  • ith possible prior art within the project

Thanks Ben, are these action items for us or has anyone been assigned to it ?

on the Website analytics I have created this issue, waiting for reply https://github.com/kubernetes/website/issues/37801

BenTheElder commented 1 year ago

Those action items were meant for me to handle, with my steering hat 😅

I'll be following up more later this week, happy to have help! The CNCF service desk is currently open to their listed official maintainers which for Kubernetes is steering, so I'll have to do that one (will file within the week and report back).

BenTheElder commented 1 year ago

Last week I got access to the service desk, today I filed CNCFSD-1530.

BenTheElder commented 1 year ago

Service Desk Response:

Thank you for logging this request.

We do not have any prior art that we recommend to gather telemetry.

If the Minikube project were to gather telemetry on command usage then any implementation would have to comply with the following Linux Foundation Policy

https://www.linuxfoundation.org/legal/telemetry-data-policy

Data collection is complicated by the need to be in compliance with regulations around the world, such as, but not limited to, the EU’s GDPR. So we think it would take a long time to review.

I have reached out to the Privacy Team to get copies of the two submissions and reviews that appear on the bottom the above policy document and I will share their response with you when it comes in.

RobertKielty commented 1 year ago

I did some more digging on this and have come up with the following reference that will probably be useful to research this topic further.

https://cd.foundation/blog/2020/04/09/spinnaker-1-18-spinnaker-community-stats/

Lot's of useful information there, in particular :

All stats collection code is open source and can be found in the Spinnaker stats, Echo, and Kork repos found on GitHub.

dims commented 1 year ago

fyi there's a LF level policy - https://www.linuxfoundation.org/legal/telemetry-data-policy

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

cpanato commented 1 year ago

/remove-lifecycle stale

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

k8s-triage-robot commented 10 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

k8s-ci-robot commented 10 months ago

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to [this](https://github.com/kubernetes/steering/issues/259#issuecomment-1900855478): >The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. > >This bot triages issues according to the following rules: >- After 90d of inactivity, `lifecycle/stale` is applied >- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied >- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed > >You can: >- Reopen this issue with `/reopen` >- Mark this issue as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.