Closed htriem closed 3 months ago
Can any more specifics around
lack of reliable infrastructure
be shared? I'm not sure if addressing that would alleviate some of the other concerns.
With regards to
testing them and supporting them
is that referencing automated testing during the build process and community support? Or Netways (the corporation)?
Personally, I think there is a lot of potential for Icinga2 (the software) to be utilized on low cost hardware as satellites (remote, smaller locations, perhaps manufacturing, etc) where local network access is preferably but the infrastructure does not necessitate a data center or even a 1U Dell. I understand that is just one anecdotal example.
It may also be worth mentioning AWS' trending towards ARM: https://aws.amazon.com/ec2/graviton/
Our build infrastructure is all x86-64 at the moment.
For one, it consists of GitHub Actions, which somehow claims ARM support ("Linux, macOS, Windows, ARM, and containers"), but as far as I can tell, they don't provide any hosted ARM runners but this only applies to self-hosted runners, which they explicitly advise against for public repositories, so unclear if GitHub Actions were the way to go if we'd want CI for PRs or if we'd have to look into other CI solutions that are integrated into GitHub.
Then we also have a self-hosted GitLab instance that we use to build our release packages with our own runners. There we could add ARM runners but to do so, we need to know where to host them, i.e. evaluate which cloud service we would want to use or if we'd want to buy hardware.
So in summary, quite some work to put into this which doesn't have a too high priority for us right now.
Oh and if you're wondering why we have builds for Raspbian and how these work: well, these are built using QEMU which is painfully slow and not really an option for extending this to more architectures and distributions.
I would highly appreciate supported Debian/arm64 packages. I would like to run native VMs on my Macbook with Apple Silicon for example.
How can I help?
As already detailed in my previous comment, it's mainly about infrastructure (combined with the lack of demand by our paying customers). From a code perspective, things should be just fine (we don't really do architecture-specific stuff, so if it has a working C++ compiler, it should work), so if you want to do that, nothing stops you from building your own packages and providing them to the community.
CircleCI has Linux arm64 runners, works fine. Not sure why Github hasn't done it yet. Anyway, CircleCI is modest cost for something like this.
I've set up a package repository for arm64 debian bullseye packages. It's publicly available, you find the details here: https://github.com/izkasi/icinga_arm64
@rfay Gitlab-runners are supported on linux-arm64 as well. I tested builds on AWS Graviton(arm64)(with Debian bullseye), works fine. Just for future reference.
I would also like a package for RH-based (Fedora in my case) ARM64. I lack the knowledge on how to build this myself unfortunately.
I noticed that there are arm64 packages of 2.13.8 and 2.14.0 for Debian. Can you build these for Ubuntu as well?
I would like to put agents on my Raspberries...
I would also like to use the Ubuntu package on arm. It seems like the currently provided arm package is 17 releases behind the current one.
I'm working on deploying Icinga through NixOS as there is an Icinga2 Nix package available for aarch64, in case it helps anyone.
I'm working on deploying Icinga through NixOS as there is an Icinga2 Nix package available for aarch64, in case it helps anyone.
It would be awesome if you could share your configuration, if you manage to run it.
I'm working on deploying Icinga through NixOS as there is an Icinga2 Nix package available for aarch64, in case it helps anyone.
It would be awesome if you could share your configuration, if you manage to run it.
Unfortunately, I was just able to get the container image working on aarch64
, so I'll probably be going that route for the server aspect of Icinga2. I'm not sure if I'll end up configuring the agent directly on a host in the future though.
Here we discuss the viability, demand and effort required to support ARM architecture for our packages. A big issue on the way there is our lack of reliable infrastructure for building such packages, testing them and supporting them. There are also questions about how well it might integrate with our current infrastructure (GitHub Actions, GitLab CI) and what the most efficient way of going about this might be.
refs
131
172
199
200
209
218