Rudder

Some more information:

In some (but not all, and for now we don't know exactly on which), the Fusion reports contains both:

    <HARDWARE>
      <ARCHNAME>x86_64-linux-thread-multi</ARCHNAME>
      ...
    </HARDWARE>

And:

    <OPERATINGSYSTEM>
      <ARCH>i686</ARCH>
      ...
    </OPERATINGSYSTEM>

So we could use the second one, which is what we need / want.

There is still three things to take care of in that case:

- 1/ we need to be sure that all supported agent version have a fusion that fill that ARCH attribute
- 2/ we need to be sure to correctly migrate existing groups using "ARCH" (with the case of API, and certainly a compatibility option to add for them)
- 3/ that does not solve the problem that Fusion is not using the correct information for its own internal decision making.

In fact, I'm not sure we should port existing groups, perhaps just disable them because the are MOST LIKELY false, i.e the user is most likely not doing what he thinks he is doing. So perhaps we should just correct in next minor...

So, after some more research:

- linux has the ARCH field at least since rudder 2.11, with the correct content (i686, x86_64)
- windows get 32-bits, 64-bits
- AIX does not have the field at all
- rasperry get the expected content ("armv7l")

So, I propose to just use the new field, with ppc64, i686, x86_64, etc. If the field ARCH is not present, try to infer the correct content from OS or HARDWARE/ARCHNAME.

The group search is a free input field, so nothing to change here.

We will need to make a breaking change annoucement in the release note for 4.1.
We will also need to look for "aix-thread-mutli, armv7l-linux-thread-multi, MSWin32-x64-multi-thread, (well, anything not looking like ".x64.*") and try to migrate it and make a big warning in logs.

For the feature, I opened #11994.