Agreeing with Nick, it seems like the main reason people are building themselves, and hitting all these environmental issues, is that we do not as a project produce binary release artefacts (the rpms which users could just install) and instead leave that for the commercial distributors to do.
Yarn may help with some of the dependency version issues we’re having, but not afaik with the core missing library headers / build tools / node and npm version issue, those would seem to fit a documentation fix and improvements to platform-info to flag the problems, so this can then be a pre-flight check tool as well as a diagnostic tool. Another option I would put on the table is to standardise our build environment, so that the non-java bits are run in a standard docker image or something fo the sort, that way we can take control of all the environmental and OS dependent pieces, much as we do right now with the rpm build sections of the mpack build. The challenge here will be adding the relevant maven support. At the moment we’re relying on the maven npm and node build plugins, this would likely need replacing with something custom and a challenge to support to go dow this route. Perhaps the real answer here is to push people who are just kicking the tyres towards a binary distribution, or at least rpm artefacts as part of the Apache release to give them a head start for a happy path on a known good OS environment. Simon > On 24 Nov 2017, at 16:01, Nick Allen <n...@nickallen.org> wrote: > > Yes, it is a problem. I think you've identified a couple important things > that we could address in parallel. I see these as challenges we need to > solve for the dev community. > > (1) NPM is causing us some major headaches. Which version do we require? > How do I install that version (on Mac, Windows, Linux)? Does YARN help > here at all? > > (2) Can we automate the prerequisite checks that we currently do manually > with `platform-info.sh`? An automated check could run and fail as part of > the build or deployment process. > > > > More importantly though is that users should not have to build Metron at > all. They should not have to worry about installing NPM and the rest of > the development tooling. Here are some options that are not mutually > exclusive. > > > (1) Create an image in Atlas that has Metron fully installed. A new user > could run single node Metron on their laptop with a single command and the > only prereqs would be Vagrant and Virtualbox. We could cut new images for > each Metron release. Or selectively cut new dev images from master as we > see fit. > > (2) Distribute the Metron RPMs (and the MPack tarball?) so that users can > install Metron on a cluster without having to build it. > > > > > > > On Fri, Nov 24, 2017 at 10:11 AM, Otto Fowler <ottobackwa...@gmail.com> > wrote: > >> It seems like it is getting *very* common for people to have trouble >> building recently. Errors with NPM and Node seen common, with fixes ranging >> from updating c/c++ libs to the version of npm/node. >> >> There has to be a better way to do this. >> >> - >> >> Are we out of date or missing requirements in our documentation? >> - >> >> Does our documentation need to be updated for building? >> - >> >> Is there a better way in maven to check the versions required for some >> of these things and fail faster with a better message? >> - >> >> Are we building correctly or are we asking for trouble? >> >> The ability to build metron is pretty important, and it seems that people >> are having a lot of trouble related to the new technologies in alerts and >> config ui. >>
