What problem/case is this additional component trying to solve?
My opinion is that it's an enable meant tool to make it easy to use
BigTop by having it's configuration managed by Ambari. Now is a great time
for making this move as HDP is no longer going to be managed by a company,
so BigTop could replace that role in Ambari.
This mpack allows BigTop to be installed into Ambari, and allows
Ambari to manage the hadoop packages. Effectively, it would increase the
reach of BigTop to be able to be installed into and managed by Ambari.
I hear that you see a lot of other priorities and they sound like good
priorities. I'm not able to contribute to those priorities as I don't know
enough in that area/do not understand what's required. I would contribute
right now to Ambari MPack as it's more in my wheelhouse.
Hope that helps
Matt
On Sun, Jun 7, 2020 at 12:07 PM Olaf Flebbe <[email protected]> wrote:
> Hi,
>
> Sorry, I am super lost about the implications of that vote.
>
> Why do we need a vote in the first place?
> I am familiar with votes for additional committers, PMC additions and
> releases. For these votes we have the concept of binding votes by PMC
> members.
>
> Why should I care about this ?
> Does it have legal implications?
>
> Who will maintain this ?
> I am a bit surprised that we do anything with ambari, since we not even
> have a maintainer for it
> grep ambari MAINTAINERS.txt -> nothing
>
> What problem/case is this additional component trying to solve?
> If you are asking for a vote I would like to have a more elaborate
> explanation. I looked at the linked ticket: Sorry I am totally lost about
> what is this about. If you would have simply done it, I wouldn’t have cared.
>
> As I understand it should somehow enable more contributions.
> Really? MPack is a amabari only technology, that seems not to even be
> defined properly. How could this ever end in more contributions to Bigtop ?
>
> What will happen if someone is -1 on this vote ?
>
> If a contributor cares about adopting Bigtop to new business cases, that’s
> very fine to me. Please go ahead. But please don’t ask for a vote. All
> committers still have the chance to reject patches.
>
> Generally I am concerned that we care about an (from Bigtop side)
> unmaintained project while neglecting our core infrastructure and packages
> at the same time.
> 1) The ci.bigtop.apache.org certificate expired again
> 2) The bigtop-trunk-packages do not reflect the architectures we ought to
> support (ubuntu-18.04 for instance)
> 3) Trunk-packages for amd64 looks like garbage
> 4) Still no-one working on Hadoop3
> 5) CI needs to be redone (with pipeline jobs) .
> IMO we might have wrong priorities.
>
> Best,
> Olaf
>
>
>
>
> > Am 04.06.2020 um 19:04 schrieb Ganesh Raju <[email protected]>:
> >
> > +1
> >
> > On Thu, Jun 4, 2020 at 12:01 PM Matt Andruff <[email protected]>
> > wrote:
> >
> >> +1
> >>
> >> On Thu., Jun. 4, 2020, 02:35 Yuqi Gu, <[email protected]> wrote:
> >>
> >>> Hi folks,
> >>>
> >>> As the discussion with Evans Ye, Jun He, and Matt Andruff (from Ambari)
> >> on
> >>> https://github.com/apache/bigtop/pull/555#issuecomment-635228180:
> >>>
> >>> For users / Bigtopers could easily modify Mapck and make contributions
> to
> >>> it like bugfix and adding more services,
> >>> How about to decouple Mpack from Ambari and put Mpack as a standalone
> >>> component in Bigtop, like *bigtop-packages/src/common/bigtop-mpack*?
> >>> If so, it's convenient for users to get and install Mpack rpm/deb
> >> packages
> >>> in their own Ambari cluster.
> >>>
> >>> The VOTE:
> >>> [ ] +1, Agree to put Mpack as a standalone component.
> >>> [ ] +0, I don't care either way.
> >>> [ ] -1, do *not * Agree.
> >>>
> >>> Look forward to your comments and feedback, thanks.
> >>>
> >>> BRs,
> >>> Yuqi
> >>>
> >>
> >
> >
> > --
> > IRC: ganeshraju@#linaro on irc.freenode.ne <http://irc.freenode.net/>t
>
>
