Support for AIX platform

[atoulme]

Component(s)

No response

Is your feature request related to a problem? Please describe.

The collector supports amd64, arm64 and ppc64le. I would like to see it support AIX as well.

Describe the solution you'd like

I would like to see how we can go about supporting AIX. I see the following tasks as part of this work:

• Identify an environment that can run on AIX
• Compile and run the equivalent tests we run for ppc64 for AIX
• Ensure that some receivers such as the hostmetricreceiver work well for AIX
• Distribute the AIX distribution

Describe alternatives you've considered

No response

Additional context

No response

[codeboten]

Would be good to understand the impact the code of testing the repo on another platform on the duration of the builds. If its negligible, and the existing tools to produce the release supports aix, i don't see any problem with adding support for this.

[mx-psi]

Support for new platforms has caused pain in the past and we have been somewhat inconsistent in what we accept (see e.g. open-telemetry/opentelemetry-collector-releases/issues/170, open-telemetry/opentelemetry-collector/issues/2437, open-telemetry/opentelemetry-collector-releases/issues/105 or the issues related to open-telemetry/opentelemetry-collector/issues/5031). We also have different levels and definitions of support for different platforms, that range from "we will accept PRs targeting that platform but won't do anything otherwise" (e.g. Plan 9, see my notes here open-telemetry/opentelemetry-collector#6924 (review)) to "we will provide builds, run unit tests on every PR"(e.g. amd64/linux), passing through "we will make sure it remains buildable, but won't run tests" (e.g. everything macOS). IMO, before discussing AIX specifically we should take a step back and define our support 'tiers'.

I like rustc's target tier policy, the situation is not identical but probably we can take something from there. The items that we can think in our case about providing support/not on are (roughly from most demanding to least demanding):

• Being able to block a release or make a bugfix release because of problem specific to a platform (i.e. fulfilling the "The bug is not specific to an uncommon platform" item from the bugfix release criteria)
• Ensuring feature parity with a reference implementation (amd64/linux) vs. allowing for dummy no-op implementations on components
• Ensuring unit tests pass on CI
• Ability to address platform-specific bugs (e.g. by having an 'owner' of the platform)
• Building and releasing official artifacts for that platform
• Ensuring the codebase builds on a given platform

My take is that we should put this on hold until we write a doc with our tiers (we can keep it simple for now, just try to roughly reflect existing practice), and define a way to move up the tier ladder (at some tier this probably means 'open an issue and get a sponsor that will own things').

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[mx-psi]

We now have a tiered platform support model, so we can start with adding tier 3 support for AIX now :) 🎉

[rrschulze]

We did some initial evaluation to build the core collector on AIX 7.2. There is at least a dependency on this issue for fsnotify on AIX that needs resolution first.

[arp242]

We did some initial evaluation to build the core collector on AIX 7.2. There is at least a dependency on this issue for fsnotify on AIX that needs resolution first.

Solving this would require having access to an AIX machine @rrschulze, or a reliable long-term maintainer with access to one. fsnotify strongly depends on runtime behaviour, so it's not a "if it compiles it'll probably be fine" type of affair.

As far as I can find, gaining access to AIX machines (VM, CI, some remote access – anything) is hard for mere mortals not part of some Enterprise License Deal™ with IBM.

So as far as I'm concerned the ball is in IBM's court here. It's a complete non-starter without some way to actually run the code.

[grhoades]

If we were to supply the infrastructure through a self-service platform that we operate would that be helpful?

[mx-psi]

@grhoades We now have a platform support doc. Adding support for AIX would mean starting from Tier 3 (guaranteed to build) and working from there. You can take a look at the PRs related to linux/s390x on this, the opentelemetry-collector and the opentelemetry-collector-releases repositories to see an example of the work needed for this.

[ThakkarChandresh]

Raised PR with working code of it!

[FreerideTheWorld]

This thread seems to be a bit out of my league but if there was a way to get OpenTelemtry collector on AIX and ship logs to Elasticsearch that would be very helpful. Sorry if this isn't a great place to post. I do understand the hurdles of development here since the AIX platform isn't something that most people have access to for development/testing.

[mx-psi]

As a summary: Tier 3 support for AIX can be added if someone leads the development and owns it. This is probably still something we need to address in some way (either with reduced functionality or by adding support for this on the dependency) #19195 (comment).

Tier 3 support only guarantees that the Collector builds on AIX, but the Collector SIG will generally not provide direct fixes to AIX-specific issues after this is added.