bigtop-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jay vyas <jayunit100.apa...@gmail.com>
Subject Re: deployment of bigtop stable release
Date Tue, 09 Jun 2015 02:10:26 GMT
@martin i like the idea of creating a wiki page for what you did with
bigtop 0.8 ... But probably we don't really have a policy on this stuff,
...  because most bigtop users are comfortable trading in the sharp edges
so that they can build all the bits on their own from scratch.

In general, we usually do this
- grab the RPMs/DEBs from jenkins, along with bigtop master.
- run puppet deploy.
If anything fails (i.e. if the RPMs are behind from the puppet recipes in
master),
we usually can just build the packages from master ourself using docker
containers, test w/ vagrant up and the --use-local-yum=true option.

thats the most common scenario and probably the most important, given that
in general its  ok if bigtop is kind of a bleeding edge distribution for
most peoples needs.

I know thats kind of a lazy cop-out of an answer, but its probably
reasonably close to the current culture we have around here :)

On Mon, Jun 8, 2015 at 3:39 PM, Martin Bukatovic <mbukatov@redhat.com>
wrote:

> On 06/06/2015 09:29 PM, Evans Ye wrote:
> > Hey Martin, sorry to reply you late.
> > I think you can also refer to my reply in "newbie question of BigTop"
> > thread for the deployment.
> > I'm sorry that the document currently we have are a little bit out of
> date.
> > So thanks for wrapping up your notes! It would be great if we can put
> > that on our wiki.
> >
> > Getting back to your questions, I think you better use puppet recipes in
> > the master to deploy bigtop clusters at this moment. The reason behind
> > this is that our puppet recipes changed a lot from 0.8 to 1.0. If you
> > don't want to learn it twice, than you better use the newest version
> > directly. :)
> > The new puppet recipes can be used to deploy bigtop 0.8 packages as
> > well. AFAIK the incomparable component should be sqoop only.
> > For bigtop users, I think it's always better to use a fix release of
> > bigtop, since the master can have broken feature during development,
> > although we tend not to.
> > Hopefully I've answered your questions. if not, welcome to ask more. :)
>
> Thanks for the answer. I will polish my notes a bit and add your
> explanation there. Then I'm expected to open new JIRA for it, right?
>
> But I have another question, does it mean that this approach (using
> puppet recipes from master to deploy both stable release and current
> master) is a desing feature of bigtop so that:
>
>  - it is going to work in the upcoming release? Will I be able to
>    use future puppet recipes from master to deploy bigtop 1.0.0?
>    Or I should rather ask: is this planned?
>  - we are suggesting to always use deployment scripts from master
>    with few exceptions (eg. sqoop you mentioned)?
>
> If it's true, we may like to advertise this a bit more.
> Maintaining list of hadoop components which are not deployable by
> current master orchestration would be nice so that we can state:
> always use master with those exceptions.
>
> --
> Martin Bukatovic
> RHS/Hadoop QE Team
>



-- 
jay vyas

Mime
View raw message