bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé <>
Subject Re: Bigtop environment setup
Date Sun, 23 Sep 2012 22:33:58 GMT
On 09/23/2012 12:06 AM, Konstantin Boudnik wrote:
> On Fri, Sep 21, 2012 at 09:20PM, Bruno MahИ wrote:
>> #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 situation.
>> 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.
>> Thoughts?
> (writing at the end of the last post feels totally unnatural, but for the
> benefit of the future readers I will comply :)
> I think boxed environments (like VMs) are an overkill. One of the issues here
> (as Anatoli pointed out) is non-even support of all OSes. Say, BoxGrinder has
> some issues with Ubuntu, etc.
> I suppose a ol' proven toolchain type of environment that can automatically
> bootstrap upon a fresh install (or update itself: think Maven model) and pull
> whatever apps are required in whatever form they might exist. Say, JDK (or
> Groovy or else) can be downloaded as a tarball, given that a more suitable
> packaging isn't available, etc. Such approach would be more fluid than a
> somewhat rigid VMs, that would have to be updated periodically, versioned,
> etc.
> Another benefit of a toolchain is that BigTop packages might have to
> redistribute/wrap some of the tools for later use once a package is installed
> on a customer's system.
> So, in other words, #2 above (or some modification of it) looks more appealing to me.
> --

I actually think boxed environments are simpler than a toolchain since 
they are more constrained. And you avoid the nasty issues with natives 
any toolchain would have.

In any case, any solution, whether it is toolchain or VMs, would have 
similar issues regarding supporting multiple OSes.

Oz seems to support partially non-rpm distributions. So that may be way 
to solve it. But worst case scenario I would not see any issue with 
having one sets of vm recipes for centos6 and another one for ubuntu 
(they can always share some common scripts).

Maintaining a toolchain with updates such as you describe also comes 
with a bunch of issues for upgrades that are non-existent for VMs. 
Considering that we are talking about helping newcomers, who will 
probably set up their own environment later on and do not necessary want 
to taint their system, VM can easily be consumed and thrown away.
You also don't have to worry about combinations of versions and packages 
or even to replace system provided packages which may disrupts other 
packages from the base OS.

I am also interested in VMs, since one of my working pattern is to have 
a base build vm that I clone for large work (new package or any 
significant work with multiple iterations). So I can locally (from my 
VM) build, install the package, test  and remove them and not care if my 
newly built package will trash my machine. This enables me to quickly 
iterates through changes without having to move packages around.


View raw message