Hey guys, after I chat with the CEO of Redoop, I have summarized their experience as follows:
Redoop has tried 3 Bigtop + Ambari options, which are: 1. Update Ambari code to adapt to Bigtop installation path(/usr/lib). 2. Update the installation path of Bigtop, install the components to /usr/bigtop/x.x, like HDP. 3. Update both Ambari and Bigtop code, Bigtop supports output the tarball of components, Ambari supports installation via tarball. The problem with the first option is that the installation paths of Bigtop components are not uniform, it's difficult to upgrade and manage. The problem with the second option is that for different combinations of operating systems and chips, components need to be recompiled to provide build scripts like RPM or DEB, which will encounter a lot of dependency problems, and it's easy to get bogged down in the details. And each component upgrade needs to recompile all components, which requires a lot of manpower to solve the compilation problem. After a period of time, they chose to give up this option due to workload issues. The third option is currently adopted by them. Since each community provides the tarball of their component, they don't need to write RPM or DEB build scripts anymore, they can focus on Ambari's code. It can also reduce a lot of labor costs to adapt to different operating systems. The problem with this option is that Bigtop needs to support output tarball for each component, while Ambari needs to support installing via tarball, which can be a lot of work.
