-
Notifications
You must be signed in to change notification settings - Fork 623
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 architecture telemetry in the gotk #493
Comments
It's really weird to make intentionally bad architectural decision (not supporting all architecture at once in multiarch build) at so early stage of development. I really like Flux, but being so rigid and not hearing users is a bad sign. If you really need telemetry, just do it correctly - built it properly, make it clear for every user and allow opt-out. This is correct behavior in open source world. |
Actually, this is breaking the telemetry. I have a multi-arch cluster and whichever I install (amd64 or arm) hides the other from the telemetry when I would be perfectly happy to let the Flux deployments roam between nodes irrespective of architecture. Effectively, I'm a would-be ARM user hidden by this choice of data collection. (I don't suppose anyone knows of a way to merge individual single-arch images into a multi-arch image?) |
@cerebrate Yes this is the considerable issue. Currently the raspbernetes image repository offers a multi-arch build of fluxv1 with about 540k worth of pulls that the flux maintainers are missing out on, on their metrics. These builds are multi-arch and can be ran on ARM64 or AMD64. You can find them here https://github.com/raspbernetes/multi-arch-images Of course if the flux maintainers opted to instead maintain a multi-arch build and depend on metrics from telemetry rather than GHCR metrics they would have a wider scope of their users. |
also a good reason for this is the last 12+ month: Nvidia aquires ARM Apple Silicon and M1 also most cloud providers have ramped up for this: so there will be fore sure multiarch Kubernetes / k3s etc clusters and if one image can rule them all ? ARM64 is not replacing AMD64 or Intel - but it can handle workloads that are not CPU hungry on ARM64 much more efficient and it would be really really nice to have the an multiarch image for flux2. Flux2 would be more approachable by the community also in the private sector.... |
Happy to announce that we simply had to wait a tiny bit till GitHub released statistics per image layer, which they just did. This means that we are now able to merge the images together and remove the arch selector from the manifests, but this will likely not happen before the new year. Best wishes, and see you in 2021 🎄 🎆 |
Evening,
I'm inquiring for the feasibility of adding telemetry to your images hosted on ghcr. I came across this discussion earlier today. It seems as though multi-arch images are not being pushed due to the ghcr registries metrics. To combat this perhaps some kind of anonymous telemetry can phone-home so the maintainers are getting an idea of what users are running as their architecture. I'm currently using a 3rd party image on fluxv1 for flux and the helm-controller to support my multi-arch cluster. It would be greatly appreciated to see proper multi-arch images for AMD64 and AARCH64. Most popular images these days are supporting multi-arch builds and getting useful metrics through anonymous telemetry. Is there any interest in adding this since we're in active development?
The text was updated successfully, but these errors were encountered: