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.
Thanks,
Bruno
