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

[Merlijn Sebrechts]

Awesome! Thanks! We'll let you know if we run into any issues.

2017-04-20 6:15 GMT+02:00 Kevin Monroe <kevin.monroe at canonical.com>:

> 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/20170420/25684fe3/attachment.html>