Hi cos!  I like the goal, but let me pervert your idea a little bit :) ....
how does this sound ?

*** Definetely ***

lets keep going w/ gradle for all build/test/deploy stuff.  Its great for
that !  Full court press to remove maven deps, gradle is wayyyy cleaner and
definetely is the future trend.  the hard work you've done in integrating
the whole build to use it is really making bigtop a fun to use packaging
system, and actually has made me more able to contribute to it b/c its
easier to debug the build now for guys like me that dont know much about
make.

*** BUT ***

although I LOVE the idea of adding a CONTROLLER to the live machines, ...
adding it in gradle? very few devops folks will really want to use gradle
for that kind of task....  its not the idiom.

One of the HUGE selling points of bigtop is that it has puppet recipes,
rather than just one of commands/tasks for managing the cluster - the ops
community can read and understand those easily.

*** SO : PUPPET MASTER .... AN ALTERNATIVE ? ***

I think, if we want to manage LIVE machines, then can i suggest a real
puppet master implementation? If we go that route, you get all the testing
for it also, for free, w/ our existing vagrant recipes.... and its in line
w/ what the devops community is doing, and so it will help drive bigtop
adoption.


On Fri, Dec 19, 2014 at 8:19 PM, Konstantin Boudnik <[email protected]> wrote:
>
> Guys,
>
> I've been doing some thinking lately (yes, I know I shouldn't - I've heard
> this from good friends before, but can't help it) and it makes more and
> more
> sense to me to wrap more build/deploy functionality into our Gradle build.
>
> The low-hanging fruits I have in mind right now is to provide a wrapper for
> {{puppet apply bigtop-deploy/puppet/manifests/site.pp}} that will do a few
> things like:
>  - copy deployment recipes to all specified hosts, including site.csv file
>  - start puppet apply on all hosts in parallel using gradle ssh plugin
>
> This, IMO, will provide us with a very easy and transparent way of quickly
> deploying cluster bits as one works on something, without switching out of
> the
> convenient build environment. Sorta, change-deploy-rinse-and-repeat loop.
>
> The same gradle task can be called, if desired from Jenkins or else.
>
> Do you think it worth it? Thoughts?
> --
> Take care,
>   Cos
>
>

-- 
jay vyas

Reply via email to