Skip to content
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

Closed
anthr76 opened this issue Nov 23, 2020 · 5 comments · Fixed by #684
Closed

Create architecture telemetry in the gotk #493

anthr76 opened this issue Nov 23, 2020 · 5 comments · Fixed by #684

Comments

@anthr76
Copy link

anthr76 commented Nov 23, 2020

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?

@Marx2
Copy link

Marx2 commented Nov 23, 2020

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.

@cerebrate
Copy link

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?)

@anthr76
Copy link
Author

anthr76 commented Nov 23, 2020

@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.

@danielsand
Copy link

danielsand commented Dec 5, 2020

also a good reason for this is the last 12+ month:

Nvidia aquires ARM
https://nvidianews.nvidia.com/news/nvidia-to-acquire-arm-for-40-billion-creating-worlds-premier-computing-company-for-the-age-of-ai

Apple Silicon and M1
https://en.wikipedia.org/wiki/Apple_M1
https://en.wikipedia.org/wiki/Mac_transition_to_Apple_Silicon

also most cloud providers have ramped up for this:
AWS
packet
etc

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....

@hiddeco
Copy link
Member

hiddeco commented Dec 16, 2020

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 🎄 🎆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants