Hi Zhiguo Wu,
I think, most of us agreement that we'll work for Bigtop mpacks with bigtop
community which can used ambari trunk and replace HDP. Correct me if I am
wrong..
Following are not relate to this thread, going forward post this another thread
as discussion is different.
>> The branch management still need to be discussed, the branch `trunk` is
>> quite different from the tag `release-2.7.6-rc1` code. Honestly, I don't >>
>> know what features have changed.
>> So I suggest we could checkout two branches from tag
`release-2.7.6-rc1`, maybe we should name it `branch-2.7` and `main`?
Branch-2.7 and trunk we'll use as mentioned in the roadmap mail thread. Hope
that clears you.
>> Regarding PlanA mentioned by Brahma, since Bigtop already provided fully
>> tested and compatible component versions, why do we need to >>define a stack
>> ourselves? We can simply use the stack provided by Bigtop. Therefore, Bigtop
>> can focus on component integration testing and >>compatibility, and Ambari
>> can focus on component management and monitoring.
Currently Bigtop stack is very old which is in branch-2.7 and we need to define
newer with latest versions of components.
>> Regarding PlanB mentioned by Brahma, I also have the same question, what
>> should we do to avoid developing a new stack?
Upgrade of existing cluster can be easier,As we can avoid two
selects(hdp-select,...) same code.
On 20/06/22, 2:14 PM, "吴治国" <[email protected]> wrote:
Thanks Kengo,
To be honest, I would prefer that we can help to support more Bigtop 3.1.0
based components for bgtp-ambari-mpack.
Since the code is the same, we can easily copy the code in mpack to Ambari,
which is equivalent to developing Ambari 2.8.0 at the same time when we are
developing the mpack.
The branch management still need to be discussed, the branch `trunk` is
quite different from the tag `release-2.7.6-rc1` code. Honestly, I don't know
what features have changed.
So I suggest we could checkout two branches from tag `release-2.7.6-rc1`,
maybe we should name it `branch-2.7` and `main`?
Regarding PlanA mentioned by Brahma, since Bigtop already provided fully
tested and compatible component versions, why do we need to define a stack
ourselves? We can simply use the stack provided by Bigtop. Therefore, Bigtop
can focus on component integration testing and compatibility, and Ambari can
focus on component management and monitoring.
Regarding PlanB mentioned by Brahma, I also have the same question, what
should we do to avoid developing a new stack?
Best Regards,
Zhiguo Wu
> On Jun 20, 2022, at 11:23, Kengo Seki <[email protected]> wrote:
>
> Sorry, I have one question.
> Assuming that we support HDP in the 2.7.x line, can we still download
> and deploy its packages from a public repository?
> I think Cloudera's repositories went behind a paywall, but maybe I
> don't understand its usage or terms of use so much.
>
> Kengo Seki <[email protected]>
>
> On Mon, Jun 20, 2022 at 10:30 AM Kengo Seki <[email protected]> wrote:
>>
>> Zhiguo's opinion sounds reasonable to me. Let me clarify a few things
>> (correct me if there's any misunderstanding, Zhiguo):
>>
>>> Bigtop mpack will not immediate goal for us at least for 2.7.7, as
there will be lot work needs to done
>>
>> Bigtop Mpack is developed by the Bigtop community, and Yuqi is
>> actively working on it in BIGTOP-3689.
>> So we just help it (for example, giving them some advice if asked) on
>> the Ambari side and our main focus is still the next Ambari release.
>> (That being said, the current Mpack only supports ZK and Hadoop, so if
>> someone is willing to add other components to it, it will be really
>> welcomed!)
>>
>>> And when the time comes for 2.8.0 (or 3.0.0), we can discuss more about
moving towards "bigtop mpack" based support only.
>>
>> I don't think that's what Zhiguo meant. On the contrary, he meant:
>>
>> * For Ambari 2.7.5 (and maybe 2.7.6), we can provide the Bigtop stack
>> only through Mpack, so we use it.
>> * Since Ambari 2.8.0 (or 2.7.7?), we replace the default stack with
>> Bigtop's one as built-in, which allows us to drop the Bigtop Mpack.
>>
>> Kengo Seki <[email protected]>
>>
>> On Mon, Jun 20, 2022 at 8:33 AM Viraj Jasani <[email protected]> wrote:
>>>
>>> FWIW, I agree with Brahma, we should focus on releasing 2.7.7 to get the
>>> dev/test efforts rolling first before we shift our attention to "bigdop
>>> only" releases for Ambari. And when the time comes for 2.8.0 (or
3.0.0), we
>>> can discuss more about moving towards "bigtop mpack" based support only.
>>>
>>> On Sun, Jun 19, 2022 at 9:21 AM Battula, Brahma Reddy
>>> <[email protected]> wrote:
>>>
>>>> IMO, Bigtop mpack will not immediate goal for us at least for 2.7.7, as
>>>> there will be lot work needs to done to support latest stack and
existing
>>>> the cluster upgrades.
>>>>
>>>> I am preparing draft road map. Let's see how that can be.
>>>>
>>>>
>>>> On 19/06/22, 9:42 PM, "吴治国" <[email protected]> wrote:
>>>>
>>>> Hey guys,
>>>>
>>>> There are some difficulties for users to use Ambari since HDP is
>>>> behind the paywall, I think this is the first problem we have to solve.
>>>> Because the Bigtop stack is fully tested, and it's also belongs to
>>>> ASF, I think it's an ideal choice.
>>>>
>>>> Since Ambari 2.7.5 and 2.7.6 have been released, there are limited
>>>> things we can do, so I consider:
>>>> 1、We should help Bigtop community to provide bgtp-ambari-mpack to
>>>> support Ambari 2.7.5 and 2.7.6.
>>>> 2、Start the development of Ambari 2.8.0, in this version, I prefer
to
>>>> drop HDP completely and use Bigtop as default.
>>>>
>>>> Normally, from Bigtop side, a Bigtop version only supports one
Ambari
>>>> version, and current bgtp-ambari-mpack is for Ambari 2.7.5, so I think
we
>>>> can first consider the combination of Bigtop 3.1.0 + Ambari 2.7.5.
>>>> Users can download Ambari 2.7.5 from the Bigtop release site by
>>>> setting the OS repository, and install bgtp-ambari-mpack manually.
>>>>
>>>> Regarding Ambari 2.7.6, we can consider it later.
>>>> Regarding Ambari 2.8.0, I'm more inclined to support Bigtop 3.1.0
>>>> first.
>>>> What do you think?
>>>>
>>>> Best Regards,
>>>> Zhiguo Wu
>>>>
>>>>
---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
