bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Bigtop environment setup
Date Thu, 20 Sep 2012 01:55:59 GMT
Good idea, guys.

I envision something like 2) with a very thin layer of automation written in
Groovy to generate dependency lists and run needed install commands. 

I argue for Groovy, because any kind of programming in shell ends up in an
awful mess.

Cos

On Wed, Sep 19, 2012 at 06:32PM, Roman Shaposhnik wrote:
> On Wed, Sep 19, 2012 at 6:00 PM, Anatoli Fomenko <afomenko@yahoo.com> wrote:
> > I found that in order to avoid unnecessary build failures I need to quickly set
up additional
> > 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.

Mime
View raw message