Mattermost-server: Addd arm64 management for plugins

[protheusfr]

Mattermost work well on arm / arm64 (thanks to Go), but they are artificially locked to adm64 arch for plugin management.

Is it possible to update the following code on model/manifest.go:193:

type ManifestExecutables struct {
    // LinuxAmd64 is the path to your executable binary for the corresponding platform
    LinuxAmd64 string `json:"linux-amd64,omitempty" yaml:"linux-amd64,omitempty"`
    // DarwinAmd64 is the path to your executable binary for the corresponding platform
    DarwinAmd64 string `json:"darwin-amd64,omitempty" yaml:"darwin-amd64,omitempty"`
    // WindowsAmd64 is the path to your executable binary for the corresponding platform
    // This file must have a ".exe" extension
    WindowsAmd64 string `json:"windows-amd64,omitempty" yaml:"windows-amd64,omitempty"`
}

By

type ManifestExecutables struct {
    // LinuxAmd64 is the path to your executable binary for the corresponding platform
    LinuxAmd64 string `json:"linux-amd64,omitempty" yaml:"linux-amd64,omitempty"`
    // DarwinAmd64 is the path to your executable binary for the corresponding platform
    DarwinAmd64 string `json:"darwin-amd64,omitempty" yaml:"darwin-amd64,omitempty"`
    // WindowsAmd64 is the path to your executable binary for the corresponding platform
    // This file must have a ".exe" extension
    WindowsAmd64 string `json:"windows-amd64,omitempty" yaml:"windows-amd64,omitempty"`
    // LinuxArm64 is the path to your executable binary for the corresponding platform
    LinuxArm64 string `json:"linux-arm64,omitempty" yaml:"linux-arm64,omitempty"`
}

?

[amyblais]

@protheusfr I can ask our team about this. What is the reason behind the request?

[protheusfr]

Hello @amyblais ,

We use Mattersmost in an ARM64 server and would like to use some existing plugins.
Most of them can be easily recompiled for ARM64 but the artificial limitation in model/manifest.go (see my initial message) avoid to achieve that.

[harshilsharma2]

@protheusfr just out of curiosity, are you able to run Mattermost fine on ARM64 machine?

[protheusfr]

Yes, without any issue, in version 5.22.0, on docker mode in a K8s cluster.

[harshilsharma2]

@protheusfr very interesting! I didn't know go can compile for ARM.

[protheusfr]

Go is very versatile you can cross compile on any platform for any platform on this list :

  | $GOOS | $GOARCH
-- | -- | --
  | aix | ppc64
  | android | 386
  | android | amd64
  | android | arm
  | android | arm64
  | darwin | 386
  | darwin | amd64
  | darwin | arm
  | darwin | arm64
  | dragonfly | amd64
  | freebsd | 386
  | freebsd | amd64
  | freebsd | arm
  | illumos | amd64
  | js | wasm
  | linux | 386
  | linux | amd64
  | linux | arm
  | linux | arm64
  | linux | ppc64
  | linux | ppc64le
  | linux | mips
  | linux | mipsle
  | linux | mips64
  | linux | mips64le
  | linux | s390x
  | netbsd | 386
  | netbsd | amd64
  | netbsd | arm
  | openbsd | 386
  | openbsd | amd64
  | openbsd | arm
  | openbsd | arm64
  | plan9 | 386
  | plan9 | amd64
  | plan9 | arm
  | solaris | amd64
  | windows | 386
  | windows | amd64

[cpoile]

@lieut-data or @levb should this go on one of our team's boards? Perhaps add it to server, the starter template, and the makefile?

[lieut-data]

I'm hesitant to do anything for plugins until we also ship and support an arm-compatible Mattermost server. It's awesome to hear that it works "out of the box", but I don't think we should add arm64 support piecemeal right now. cc @aaronrothschild for thoughts.

@protheusfr, while the Executables map has this restriction, the Executable string des not. If you define that instead, it will skip all the architecture checks and run whatever binary is specified there. Since you're already rebuilding plugins yourself, you can just tweak the plugin.json as such:

     "version": "0.13.0",
     "min_server_version": "5.12.0",
     "server": {
-      "executables": {
-          "linux-amd64": "server/dist/plugin-linux-amd64",
-          "darwin-amd64": "server/dist/plugin-darwin-amd64",
-          "windows-amd64": "server/dist/plugin-windows-amd64.exe"
-      }
+      "executable": "server/dist/plugin-linux-arm64"
     },
     "webapp": {
         "bundle_path": "webapp/dist/main.js"

and bypass this artificial limitation.

[protheusfr]

Thanks for the tip @lieut-data , and yes, I use ARM64 version(in a Kubernetes cluster of Raspberry 4) in production since months without any issue, neither performance or suspect messages in logs.
It work like a charm.

[harshilsharma2]

Maybe we can ARM-compatible Mattermost release in the future? Apple is also working on ARM CPUs in new MacBooks 😛

[protheusfr]

Not sure about the pertinence to host Mattermost on a laptop, but the entire server industry has begun a (long) switch to ARM architecture. AWS sale Cloud instances (EC2A1) on ARM (graviton), servers CPU makers announce new products (Ampere, Triton, ...) and hardware distributors are preparing or began to sell new servers class ARM-based.
Due to the capability of this kind of architecture to easily multiply the number of core and keeping an efficient energy consumption ratio, I'm sure more and more Cloud provider / companies will begin to use them more widely.

Technologies like Go allow a near no cost migration, then from my perspective the products that are ready for this new market has a clear advantage.

[aaronrothschild]

@protheusfr Thank you for raising this I think it's a valid point in terms of getting ahead of the curve around upcoming hosting services that may become available. I'm a fan of "low-cost" options that help our customers deploy on the "hardware" they like.

This seems like something that should simmer in dev/test environments for a long time so issues can bubble up. As you've pointed out you've been doing that for a while. I suspect others would also start testing this if it became a part of the main branch. However, we'd have no one on the MM side QA'ing that compile option IMO. That feels vulnerable. But would move us closer to getting more adoption by people using ARM.

@lieut-data Sorry, just thinking out my position here. I'm ok with spending some effort on this - but it would need to be timeboxed IMO. 0/5

I'm hesitant to do anything for plugins until we also ship and support an arm-compatible Mattermost server. It's awesome to hear that it works "out of the box", but I don't think we should add arm64 support piecemeal right now. cc @aaronrothschild for thoughts.

@protheusfr, while the Executables map has this restriction, the Executable string des not. If you define that instead, it will skip all the architecture checks and run whatever binary is specified there. Since you're already rebuilding plugins yourself, you can just tweak the plugin.json as such:

     "version": "0.13.0",
     "min_server_version": "5.12.0",
     "server": {
-      "executables": {
-          "linux-amd64": "server/dist/plugin-linux-amd64",
-          "darwin-amd64": "server/dist/plugin-darwin-amd64",
-          "windows-amd64": "server/dist/plugin-windows-amd64.exe"
-      }
+      "executable": "server/dist/plugin-linux-arm64"
     },
     "webapp": {
         "bundle_path": "webapp/dist/main.js"

and bypass this artificial limitation.

[hanzei]

1. One concerns with including support for more architectures into the Plugin Toolkit is, that it increases the bundle size of all plugins. E.g. the GitHub plugin is 30MB big, which is considerable once an admin starts to run > 10 plugins.
2. @protheusfr Did you build your release of Mattermost yourself?
3. At least linux-arm64 and darwin-amd64 seam to be discussed here. Are there other architectures that are widely used and might need to be supported?

[lieut-data]

@aaronrothschild, agreed that it might be worth spending time on, but I'd suggest we tackle this "top-down" and have @wiersgallak evaluate priorities on supporting arm at a platform level. Plugins would naturally follow.

[protheusfr]

@protheusen Did you build your own release from Mattermost?

I only compiled the Team edition version without any modification.

cd mattermost-server/cmd/mattermost
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -i -o /go/bin/linux_arm64/mattermost

That's all (almost, I add a few ldflags for /model.BuildNumber and some additional information, and I also have to compile config_generator to produce the default config.json).

All other files come from the official binary package (fonts, i18n, templates, client, ...).
In 1995, Sun Microsystem launched the slogan "Write once, run anywhere" for the Java language, but it is also a reality for GoLang (without the memory waste).

I think you have almost nothing to do to provide (at least for Team edition) an official Linux / ARM64 distribution.
If you start with the Team edition, I suspect you have no commitment to support, so the risk is limited.

Your product is very well written and efficient, a simple $35 raspberry Pi is enough to run Mattermost for any small business (<100 people) (that's why I personally switched from Rocket.Chat to Mattermost).

You have a great product written in a technology that allows you to offer it for almost any platform, don't artificially bind yourself.

[yukiisbored]

I'm also experiencing the same issue when running Mattermost on FreeBSD/amd64.

I think a better solution would to accept any supported combination of GOOS and GOARCH in https://github.com/mattermost/mattermost-server/blob/master/model/manifest.go#L277 instead of hardcoding "supported" platforms.

To keep compatibility with old plugin.json, I think we could just use map for ManifestServer.Executables and grab the value with the key {GOOS}-{GOARCH}.

If it doesn't exist, just return a generic error that the plugin doesn't support the current platform.

[lieut-data]

@yukiisbored, I can get behind that solution, since it doesn't make us explicitly support the server on different platforms, just decouples the plugin loading code as such. We'd likely not start releasing Mattermost-authored plugins for arm64 anytime soon, but such a chance would it make it a tad easier for those who do.

[yukiisbored]

Could I make a PR that adds that functionality? I'm interested in adding this functionality since I run Mattermost on unsupported platforms.

[lieut-data]

@yukiisbored, I'd be in favour! @levb / @aaronrothschild, any thoughts to preflight @yukiisbored's efforts?

[levb]

👍 cc @hanzei

[lieut-data]

Thanks again @yukiisbored -- sorry this took so long to get merged.

[amyblais]

Ticket for reference: https://mattermost.atlassian.net/browse/MM-31988