[Meta] Mac M1 Support about elastic-agent HOT 14 CLOSED

As a consumer of Beats products, I wanted to weigh-in and request that Universal2 packages be prioritized (over different packages being made for both ARM64 and Intel architectures).

Offering Universal2 packages provides Elastic's customers with a much simpler means of deployment (insofar that deployment logic doe not need to take into account architecture given that a Universal2 package will "just work" on any device it would be deployed to).

While I understand that Universal2 packages are a bit more complex to build, the amount of headache that would be mitigated for your customers is YUGE. My organization is having a similar discussion with a lot of our vendors about this topic and -- from a customer perspective -- there is no question that Universal2 is the way to go.

My team currently manages a fleet of ~25k macOS devices and as we move hardware deployments toward Apple's M1 SoC, it would be of great benefit to have Universal2 Beats packages that will gracefully install on whatever hardware they're pushed to. Without a Universal2 package, we would then have to write additional logic to ensure that non-M1 machines get pushed the Intel package and M1 machines get the ARM64 package. While this might not seem like a big deal, it would be -- in my eyes -- unnecessary work. I say it would be unnecessary work because this is the exact reason why Apple has provided macOS application development companies the Universal2 binary: To aid in the transition between Intel and Apple SoC. That being said, for a development company to not lean-in and build Universal2 binaries equates to the development company not caring enough about their customers (and, in this case, paying customers) and merely "passing the buck" down to them to figure out.

tl;dr - I can't stress enough how much our org would prefer Universal2 packages over arch-specific packages for Beats products.

from elastic-agent.

There is still fleet-server to build for M1, and I'd also wait to have everything published, on the artefacts API as well as on the website. At least on staging

from elastic-agent.

Pinging @elastic/agent (Team:Agent)

from elastic-agent.

@nimarezainia that engineers do not have something straightforward to test M1 environment. @andresrc as it on his todo list AFAIK.

from elastic-agent.

@jlind23 we just need to chip away at this. For example could we not work on building the Universal image first? that's the main dev work.

from elastic-agent.

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

from elastic-agent.

Just for the sake of completeness, I'm linking this issue to https://github.com/elastic/infra/issues/24109 where the discussion is happening around the future of Mac workers and some recent testing that's being done for M1 workers. I would consider the M1 piece of this more or less blocked until we move forward on https://github.com/elastic/infra/issues/24109 though there could be some workarounds if they were urgently needed.

EDIT: This is not accurate. Corrected below.

from elastic-agent.

@cachedout why do you consider this as blocked until the infra issue is solved?
Be aware that @AndersonQ worked on the M1 artifact and it is almost ready to be officially release.
cc @ph

from elastic-agent.

Will the M1 binary resolve the issue where Endpoint blocks all network extensions?

from elastic-agent.

@cachedout those issues have mysteriously disappeared

from elastic-agent.

@jlind23 My mistake. I was under the impression that there were not currently M1 workers in the CI but there are indeed some static workers which we requested last year. Please disregard my comment.

from elastic-agent.

@AndersonQ as both your PRs were merged, could I consider this issue as done?

from elastic-agent.

Per discussed with @AndersonQ Only the universal is missing for now, keeping it into the backlog for the moment.

from elastic-agent.

Closing this as done as everything was achieved.
cc @ycombinator

from elastic-agent.