incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anatoli Fomenko <>
Subject Re: Bigtop environment setup
Date Sat, 22 Sep 2012 23:25:05 GMT
Option #3 looks interesting.

It does not seem that either Oz 
( or BoxGrinder 
( do not fully automatically support Ubuntu.

Do you think it is a way to use these solutions for all our supported OSes?


 From: Bruno Mahé <>
Cc: Roman Shaposhnik <>; Anatoli Fomenko <> 
Sent: Friday, September 21, 2012 9:20 PM
Subject: Re: Bigtop environment setup
On 09/19/2012 06:32 PM, Roman Shaposhnik wrote:
> On Wed, Sep 19, 2012 at 6:00 PM, Anatoli Fomenko <> wrote:
>> I found that in order to avoid unnecessary build failures I need to quickly set up
>> VMs for Bigtop supported platforms. From my experience with Precise, I would say
that it's a task that may take time.
>> Any suggestions how it could be accelerated?
> You're raising a very good point, actually. In fact I've run into
> this very issue while trying to configure an extra Jenkins
> slave for bigtop01.
> Now, in the ideal world, all the build time dependencies
> that we have would be packaged and we'd express the
> fact that we depend on them via the very same packages
> that we're maintaining. That's what RPM's BuildRequires:
> and DEB's Build-Depends: fields are for -- to tell you
> explicitly what's required to be installed on the system
> before you can do the build of the package.
> Then you'd use the tools like:
>      apt-get build-dep
>      yum-builddep
> to satisfy all the dependencies and you're done.
> Now, this works great in the environment where
> you already have source packages which you
> can give to apt-get build-dep/yum-builddep
> But Bigtop has to be bootstrapped from the source.
> We can't assume existence of source packages.
> So here's the question to the bigger Bigtop
> community -- how do we want to proceed to
> manage repeatable build environments for
> our packages?
> The options I see are:
>     #1 maintain a parallel (very shallow) collection
>          of puppet code that would, essentially,
>          manage our "build slaves"
>     #2 do #1 but automate it in such a way that
>          the info actually gets harvested from
>          spec/conrol files
> Thoughts?
> Thanks,
> Roman.

#1 is nice since it can deal with non-packaging issue. But it still 
require people to install and know how to deal with puppet. From a dev 
point of view we also need to remember to not use the latest features 
since some OS lag significantly in term of versions of puppet available.

#2 is also nice since it can be dealt with the usual set of tools. But 
it still requires some effort on users. Also some dependencies are not 
and will probably never be available as packages (ex: Oracle JDK).

I also don't think there is one and only one solution.
My setup at home is quite different from the bigtop01 one.
And once you are familiar enough with Apache Bigtop and know how to set 
it up, you may find options #1 and #2 probably not well adapted to your 

So this leads me to think about option #3: VMs.
Tools like Boxgrinder and Oz can deal with multiple OSes and can create 
local images as well as push them to the cloud.
The build would be repeatable and would not require any effort from the 
end user (apart maybe providing Oracle JDK, but that would have to be 
the case whatever the solution). Future contributors would just need to 
boot their VM to get started and hopefully ease contribution.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message