FYKI, bigtop stack already merged to Ambari.
And if you are thinking about another stack-select ,I am waiting for
Roman’s opinion.
On Mon, 26 Sep 2022 at 6:15 AM, Masatake Iwasaki
wrote:
> > IMHO, Bigtop stack mpack was planned for trunk only. It could even merge
> > with a separate branch ti
IMHO, Bigtop stack mpack was planned for trunk only. It could even merge
with a separate branch till it's stable.
-1 on managing branch as we have already discussed:
On 2022/07/24 5:01, Battula, Brahma Reddy wrote:
-1 on development in branch.
> It is not worth for maintaining the branc
IMHO, Bigtop stack mpack was planned for trunk only. It could even merge
with a separate branch till it's stable.
On Thu, Sep 22, 2022 at 5:02 PM Masatake Iwasaki
wrote:
> +1
>
> On 2022/09/21 11:12, 吴治国 wrote:
> > I think we have enough to go on with Kengo’s proposal,
> > Currently we don’t hav
+1
On 2022/09/21 11:12, 吴治国 wrote:
I think we have enough to go on with Kengo’s proposal,
Currently we don’t have enough developers(and I’m not willing to) to maintain a
stack on our own like BDP.
Sure, here's my proposal:
* Stack name: "BIGTOP"
- The same name as the existing one [1]
Do we want to use the BIGTOP stack for 2.7.7 as well? Or we want to use it
for 2.8.0 and 3.0.0 onwards only to minimize the big changes for 2.7.7
patch release?
On Tue, Sep 20, 2022 at 7:12 PM 吴治国 wrote:
> I think we have enough to go on with Kengo’s proposal,
> Currently we don’t have enough d
I think we have enough to go on with Kengo’s proposal,
Currently we don’t have enough developers(and I’m not willing to) to maintain a
stack on our own like BDP.
> Sure, here's my proposal:
>
> * Stack name: "BIGTOP"
>
> - The same name as the existing one [1]
> - Because it deploys the pac
May be we can name it as bdp-select. Or (bgp-select)
-1 as we already discussed.
Thanks for your feedback, I would definitely honour it. As you are not open for
discussion and asked us raise the PR hence you thought of discussing on the PR.
What will be your final suggestion on this..?
I'
Bumping this thread.
> I thinking we should have one stack which can support for upgrading the
existing the HDP deployed clusters. Even I can see somebody asking on
bigtop[2].
+1, we should have HDP (similar) stack to support minor version upgrades.
On Mon, Sep 5, 2022 at 12:30 AM Battula, Brah
Hi @Masatake Iwasaki,
>-1 as we already discussed.
Thanks for your feedback, I would definitely honour it. As you are not open for
discussion and asked us raise the PR hence you thought of discussing on the PR.
What will be your final suggestion on this..?
@Roman Shaposhnik
I just gone thro
May be we can name it as bdp-select. Or (bgp-select)
-1 as we already discussed.
On 2022/09/01 4:43, Battula, Brahma Reddy wrote:
Ok, thanks Viraj.
Hopefully you can place here like all other how it's maintained. Let me know
any help required on this. May be we can name it as bdp-select. Or
Ok, thanks Viraj.
Hopefully you can place here like all other how it's maintained. Let me know
any help required on this. May be we can name it as bdp-select. Or (bgp-select)
https://github.com/apache/bigtop/tree/master/bigtop-packages/src/common
On 30/08/22, 5:26 AM, "Viraj Jasani" wrote:
Masatake, Brahma,
Hopefully I should be able to create Jira and PR in Bigtop. Will let you
know once ready for review. Thanks
On Tue, Aug 23, 2022 at 9:22 AM Masatake Iwasaki
wrote:
> Please file a JIRA and submit a pull request if you want to show the code
> and get feedback.
> There is nothi
Is it Sept 9th .? Or Aug,29th..?
On 23/08/22, 8:50 PM, "Viraj Jasani" wrote:
Does 25th Aug 9 pm PST (26th Aug 9:30 am IST) work?
On Tue, Aug 23, 2022 at 2:48 AM Battula, Brahma Reddy
wrote:
> @Masatake Iwasaki ,@Viraj Jasani , @Kengo Seki and others, can we get the
>
Does 25th Aug 9 pm PST (26th Aug 9:30 am IST) work?
On Tue, Aug 23, 2022 at 2:48 AM Battula, Brahma Reddy
wrote:
> @Masatake Iwasaki ,@Viraj Jasani , @Kengo Seki and others, can we get the
> final conclusion on this..?
>
> Please let me know your availability, Can have one call to discuss on
>
@Masatake Iwasaki ,@Viraj Jasani , @Kengo Seki and others, can we get the final
conclusion on this..?
Please let me know your availability, Can have one call to discuss on this..
On 24/07/22, 1:31 AM, "Battula, Brahma Reddy"
wrote:
> -1 on development in branch.
> It is not wor
> -1 on development in branch.
> It is not worth for maintaining the branch if the modules is so small
> and barely updated as explained here.
> It should not conflict to existing code.
> I feel I must check the code before check-in based on this thread.
Sure, Viraj or me can show t
> As there are different opinions on this and took long time, just to
> brainstorm all the possibilities and pitfalls.
Oh, I interpreted your words "conclude" and "finalize" as you were
going to make a final decision. Brainstorming is welcome, of course.
(But I'm not so sure if all people concern
> Technical decisions shouldn't be done on other places than public mailing
> lists,
> as described in the "Open Communications" section of [1] and [2].
> So we should conclude the discussion in this mailing list.
> (And with my poor English, I'm not so confident to catch up with your
> flue
> Looks we had so much discussed here, Let's try to conclude. Can we've one
> call on this and finalize this..?
Technical decisions shouldn't be done on other places than public mailing lists,
as described in the "Open Communications" section of [1] and [2].
So we should conclude the discussion i
Looks we had so much discussed here, Let's try to conclude. Can we've one call
on this and finalize this..?
FYI. Even looks bigtop used some where[1] also..
1. https://en.wikipedia.org/wiki/Bigtop_(Microsoft_product)
On 08/07/22, 8:06 PM, "Kengo Seki" wrote:
Thank you for your explanatio
>From the perspective of brand publicity and protection, the name bigtop is
more appropriate. Directly link the ambari and bigtop projects.
Kengo Seki 于2022年7月8日周五 22:36写道：
> Thank you for your explanation, Brahma.
> CRH (abbreviation of "CHINA REDOOP HYPERLOOP" [1]) is supposed to be a
> tradem
Thank you for your explanation, Brahma.
CRH (abbreviation of "CHINA REDOOP HYPERLOOP" [1]) is supposed to be a
trademark of Redoop, so they can name the script crh-select without
problem.
But regarding BDP for example, I can easily find products that have
the same name [2][3][4] as you already ment
>Do you mean that you're going to name the module (same as "component"
>in the Bigtop terminology, I think) bigtop-distro-select,
>and still the script in question bdp-select? If so, is there any
>reason that the script must be that name?
>(No offence, I just want to understand
>> I’d like to propose BGTP as stack name(already used in Bigtop Ambari Mpack)
>> with bgtp-select,
>
> It is a good time to get rid of useless abbreviation.
> Why not BIGTOP?
BIGTOP with bigtop-select works for me too, but the mpack is using BGTP as
stack name now.
Best Regards,
Zhiguo Wu
>
>> Sure, we can have module name like bigtop-distro-select.
>
> Do you mean that you're going to name the module (same as "component"
> in the Bigtop terminology, I think) bigtop-distro-select,
> and still the script in question bdp-select? If so, is there any
> reason that the script must be that
The following concern Masatake mentioned before is an important point,
so I talked to Brahma for clarifying his intention on the ASF Slack
yesterday.
> Multiple versions of the same package (deb/rpm) can not be installed at the
> same time.
> IIRC, HDP uses convention in which the product version
> The name of stack based no Bigtop should be Bigtop.
> If you can not accept the name like bigtop-*, the work should done
outside of Bigtop.
> I will cast -1 if someone submit a patch to add a module with the name
spoiling branding.
Sure, we can have module name like bigtop-distro-sel
I believe it's for project name. isn't it.?
On 06/07/22, 7:27 AM, "Masatake Iwasaki" wrote:
> But As we are not releasing as enterprise should be fine I think. IMO, We
need to create folders and refer stacknames so ambari-select,bigtop-select wn't
looks good.
Not fine.
We have
> Should we avoid unrecognized brand which may be trademark of someone?
> ambari-select or bigtop-select should be enough.
Not sure, where to confirm whether there is already trademark. When I googled
found so many.
But As we are not releasing as enterprise should be fine I think. IMO, We need
t
>If it is the tool to switch distribution to Bigtop and
> does not care about other distributions,
> hosting it in Bigtop as bigtop-select would make sense.
> If the tool need to care about distribution other than Bigtop,
> it should be under Ambari.
All the component rpm's creation[1] wi
Hi Masatake,
Ambari needs rpms of select package just like we need rpms of the Bigdata
packages.
At my place, we follow the practice of keeping hdp-select and conf-select
as separate scripts as part of a new github project and let bigtop generate
rpms from this github source. For opensource commu
> Could you elaborate the reason why we need the *-select if so?
Firstly we'll not multiple select's right..? We can have distro-select and
conf-select which can be included as part of the bigtop code. User's can adopt
it and even they can write their own. And user will not deploy with multi
> Multiple versions of the same package (deb/rpm) can not be installed at the
> same time.
I dn't think, we'll required to install multiple versions same time. Even this
can be handled.
Anyway Bigtop will be used to create the RPM's not for deploying the cluster
with ambari now.
> I feel hdp-
Thanks @Kengo Seki and your team to support us.
IMO, it should ok to work on separate branch now.
@Andrew Purtell update-alternatives can be good option. we need to change the
spec files also. Is it okay to do it in separate branch and explore more as we
need to support redhat also..?
On 03/
You have Debian's 'alternatives' as a model for developing a new
"hdp-select" for a LSB compliant installation. See
https://wiki.debian.org/DebianAlternatives . The "hdp" package may
primarily install itself into a place like /usr/lib/-
or /usr/lib// but configuration files may be symlinked
into /e
Thank you for proposing this, Viraj and Brahma.
This proposal may feel sudden to someone, so let me explain some context,
mainly to the Bigtop community.
Ambari went to Attic once due to inactivity,
but some of its users and developers are reviving it now.
>From the Bigtop community, Roman and Eva
Thanks @Viraj Jasani to start discussing on this.
IMO, For upcoming ambari release(2.7.7) , we should have select other than HDP
so that people can start using the ambari without HDP.
I am +1(non-binding) on this approach to have selects in bigtop code. May be
for long term , we can think for t
Hi Ambari/Bigtop dev,
As per the new roadmap of Apache Ambari, we would like to propose moving
certain scripts (previously known as hdp-select and conf-select) to Bigtop
so that their rpm installation could be managed independently.
These scripts are a basic necessity in the Ambari framework for t
38 matches
Mail list logo
