When will the Charms get updated to Bigtop 1.2.x?

[Kevin Monroe]

Hey Merlijn!

On Wed, Apr 19, 2017 at 2:31 AM, Merlijn Sebrechts <
merlijn.sebrechts at gmail.com> wrote:

> I see Bigtop 1.2.x is released. Is there a timeframe as to when the Charms
> will be updated?
>

The apache-bigtop-base layer has been updated to pull from the bigtop-1.2
repo:

https://github.com/juju-solutions/layer-apache-bigtop-base/commit/8f5f8f3191164843ed7c7de60fed3869b4f6843a

This means any bigtop charm that has been rebuilt in the last week will
grab 1.2 packages.  Charms from ~bigdata-charmers have been rebuilt and
released to the "candidate" channel as follows:

releasing cs:~bigdata-charmers/hadoop-namenode-14
releasing cs:~bigdata-charmers/hadoop-plugin-14
releasing cs:~bigdata-charmers/hadoop-resourcemanager-15
releasing cs:~bigdata-charmers/hadoop-slave-14
releasing cs:~bigdata-charmers/hbase-5
releasing cs:~bigdata-charmers/kafka-13
releasing cs:~bigdata-charmers/mahout-5
releasing cs:~bigdata-charmers/pig-6
releasing cs:~bigdata-charmers/spark-32
releasing cs:~bigdata-charmers/zeppelin-9
releasing cs:~bigdata-charmers/zookeeper-18

You can deploy any of these by specifying the exact charm revision or by
using "--channel candidate".  For example:

juju deploy cs:~bigdata-charmers/hadoop-namenode-14

or:

juju deploy hadoop-namenode --channel candidate

FWIW, bigtop-1.2 brings our versions up to:

hbase 1.1.3-1
kafka 0.10.1.1-1
mahout 0.12.2-1
namenode 2.7.3
pig 0.15.0
resourcemanager 2.7.3
slave 2.7.3
spark 2.1.0-1
zeppelin 0.7.0
zookeeper 3.4.6-1

We have not made a formal release yet because we have 2 blocking issues:

HBase broken on ppc64le:
https://issues.apache.org/jira/browse/BIGTOP-2740

Zeppelin init script broken:
https://issues.apache.org/jira/browse/BIGTOP-2742

Once these issues are addressed, I'll release charms to the stable channel
and make a formal announcement.


> Have you made any progress on enabling deploying from bigtop trunk?
>

You bet!  We landed the ability to switch bigtop repos at build-time with
this:

https://github.com/juju-solutions/layer-apache-bigtop-base/pull/56

This lets you set 'bigtop_version' in a local copy of
layer-apache-bigtop-base/layer.yaml and rebuild charms so they'll pull from
either 1.1.0, 1.2.0, or master (i.e.: trunk).

That's cool, but I understand that not everyone wants to rebuild every
bigtop charm with a local bigtop-base layer.  Go figure ;).  We're working
on moving this to a config.yaml option so people can change the bigtop repo
post-deployment.  That's tricky because we do things in our bundles like
colocating the namenode/resourcemanager or datanode/nodemanager on the same
machine.  We need to be careful if we want to allow 1 application to use a
repo that differs from other bigtop apps on the same unit.  Or perhaps put
all bigtop apps on a unit into a blocked state until all of them are
configured to use the same repo.

Please let me know if you have any feedback on the candidate charms or the
use of "bigtop_version" as a layer option.  I'll be sure to update the list
when the outstanding bigtop-1.2 charm blockers are addressed.

Thanks!
-Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bigdata/attachments/20170419/eb7d0101/attachment.html>