Hi Michiel, It will be a web project originated from ambari earlier branch. Its back-end, we will refactor, make it more readable and succinct. When it finished and tested on schedule, I will try to push it into bigtop repo(make it work well with bigtop package system). Thanks, Peng Lee.
Michiel Verheul <[email protected]> 于2022年4月7日周四 02:01写道： > Thank you all for responding on this subject. > I agree with Kengo that these mpacks will be horrible to maintain and I can > understand that it's (at least) questionable to include that in the bigtop > repository. > Maybe I will push my current (WIP) mpack to my local GitHub, but it feels > like the right way forward would be 李帅's work. > @李帅: Do I understand correctly that your work (when complete) will result > in a new separate bigtop component, independent from Ambari? > > Michiel > > Op wo 6 apr. 2022 13:21 schreef 李帅 <[email protected]>: > > > Now, there are no replacements for Ambari. I am refactoring an earlier > > branch ambari to make it work well with > > bigtop components. it will be one web gui tool for bigtopers to deploy > and > > monitor components (no need > > install agents). > > > > John Gibson <[email protected]> 于2022年4月6日周三 10:34写道： > > > > > Hi Michiel, > > > > > > I really appreciate your offer, that sounds very useful for the HDP > > users. > > > But to be honest, I'm afraid I'm a bit reluctant to include it into > > Bigtop, > > > due to the following reasons. > > > > > > 1. Ambari has already been retired this January [1]. > > > Keeping retired software as a Bigtop component > > > brings us security risks and maintenance cost. > > > Especially, Ambari depends on several obsolete > > > softwares such as Python2 and Bower. > > > So I personally think we should drop Ambari > > > (and also Mpack) at some point in the future, > > > unless it revives. > > > > > > 2. Cloudera has changed the license of their product [2], > > > so I'm not sure if we could do that. Doesn't it violate > > > their license to install and use HDP without subscription? > > > If the new Mpack is derived from their product, > > > could we include it in our distributions > > > from the viewpoint of license compatibility [3]? > > > > > > But the above is just my personal opinion, so I'd like to hear from > > others. > > > > > > [1]: https://lists.apache.org/thread/m5jrpn4j28kn3wfn4zzxvy0g450vdlr1 > > > [2]: https://www.cloudera.com/downloads/paywall-expansion.html > > > [3]: https://www.apache.org/legal/resolved.html > > > > > > Kengo Seki <[email protected]<http://apache.org/>> > > > > > > > > > Hi Kengo, > > > > > > Sorry if you get this twice; I wasn't subscribed when I made my initial > > > reply. > > > > > > In regards to #2, licensing. Even if HDP did change the license when > they > > > expanded their paywall that could only apply to newly downloaded > copies. > > > The terms of the Apache, GPL, and most other open source licenses do > not > > > allow the author to rescind rights to users who previously obtained the > > > software. So anyone who created a mirror of the legacy HDP repositories > > > prior to the paywall deployment (3.1.4 and earlier, I believe) would > > > benefit from Michiel's work. Users without an existing legacy mirror of > > the > > > HDP repositories could only benefit if they paid to access Cloudera's > > > repositories. I'm not sure how many existing HDP users would like to > move > > > to BigTop, but this would be a nice stepping stone. The lack of a > working > > > MPack in BigTop is currently limiting our use of BigTop. > > > > > > Are there any obvious replacements for Ambari going forward? Or would > we > > > just be left without a stack-management API and GUI? The dependence > upon > > > Python 2.7 is not good, but also not a showstopper for our deployments > on > > > CentOS 7/RedHat 7, which continues to backport fixes to Python 2.7 > > (because > > > a whole bunch of that OS's software relies upon Python 2.7). > > > > > > John Gibson > > > > > > > > >
