incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anatoli Fomenko (JIRA)" <j...@apache.org>
Subject [jira] [Created] (BIGTOP-720) Build environment automation
Date Fri, 28 Sep 2012 04:25:07 GMT
Anatoli Fomenko created BIGTOP-720:
--------------------------------------

             Summary: Build environment automation
                 Key: BIGTOP-720
                 URL: https://issues.apache.org/jira/browse/BIGTOP-720
             Project: Bigtop
          Issue Type: Task
          Components: General
            Reporter: Anatoli Fomenko
            Assignee: Anatoli Fomenko
             Fix For: 0.5.0


Summary of the bigtop-dev discussion:

A few approaches have been suggested:
# (Roman) maintain a parallel (very shallow) collection of puppet code that would, essentially,
manage our "build slaves"
# (Roman) do #1 but automate it in such a way that the info actually gets harvested from spec/conrol
files. (Cos suggested to use Groovy for implementation)
# (Bruno) VMs.

There are some pros and cons for each of them.

For example:

#3 Pros: 
(Bruno) 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.
(Roman) I'd love if I could say
{code}
$ vagrant add box/up
{code}
and get the environment up and running without much fuzz.

#3 Cons:
(Cos) I think boxed environments (like VMs) are an overkill... old 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... 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.

There are some tools based on SRPMs that can extract a dependency list.

Roman suggested a simpler approach of grepping and using sed/awk: 
{code}
$ git grep -E 'Build(Requires|-Depends):'
{code}

Sean was ... in favor of the idea of extracting dependencies from the control and spec files
and building a script that will install the necessary tool chain. 

Cos mentioned ... It should work, except for build-time dependencies which aren't declared
in the bigtop packages (e.g. libtool, etc.). So, I'd vote for a separated list of build-time
dependencies being maintained.

Roman separated 3 distinct use cases:

# provisioning/maintaining a long running Jenkins slave
# provisioning a host dev environment
# provisioning a VM dev environment

Roman also suggested ... a 'virtual' package called build so that running:
{code}
$ make build-[rpm|deb]
{code}
will create a package that would download all the bits and pieced of a tool-chain AND also
promote BuildRequires: to its own Requires: so that installing this package will give you
all the toolchain bits and all the package deps at the same time.

The consensus seems to be that all approaches are valid for some use cases, so implementation
may start from simpler approaches, and evolve as necessary.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message