bigtop-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Bigtop Multiple Versions
Date Mon, 04 Apr 2016 15:44:18 GMT
From where I stand, branches would be the most appropriate way of achieving
the goal. After all, do you really want to do a VCS job yourself? 

If you indeed do want that job, then you can consider having multiple version
of the same package within the same BOM, and you'd have to control their
version in the way of naming the components differently. In your case, it'd be
spark_1.3, spark_1.5 and so on. In a way we are doing this with sqoop,
although the premise was different - out users wanted to install old and new
sqoop alongside.

Cos

On Sun, Apr 03, 2016 at 11:07PM, Kyle B wrote:
> Hello,
> 
> I’m new to Bigtop, just starting to incorporate it into where I work, and
> had a general question. Is there a recommended way for managing multiple
> versions of the same package in Bigtop? As an example, I’d like to use
> Bigtop to manage multiple builds of Spark (1.3, 1.4, 1.5, 1.6).
> 
> I tried updating the BOM to have multiple Spark definitions, and ran into
> some issues doing that. As each version could potentially require custom
> patches, I don’t want to have just one spark and update the version number
> during the build.
> 
> I’ve thought about creating different branches for each version of Spark,
> and applying the appropriate patches in each branch, but I’m wondering if
> there’s a better way?
> 
> This isn’t specific to Spark. We’re currently in the process of upgrading
> our Hadoop cluster from 2.2 to 2.7, and wanted to have two different
> versions of Hadoop I could toggle back and forth between.
> 
> So I guess my question is, is there an easy way for managing different
> versions of the same package in Bigtop without going down the git branches
> road? Any advice you can offer for best ways to do this is much appreciated.
> 
> Thanks,
> 
> -Kyle

Mime
View raw message