=== frankban|afk is now known as frankban
[08:46] <kjackal> admcleod: so in order to use the latest packages and distribution of bigtop you will need to change the following configuration variables
[08:48] <kjackal>  "bigtop_version":
[08:48] <kjackal>    "bigtop-master"                                                                                    "bigtop_release_url": "https://github.com/apache/bigtop/archive/master.zip"
[08:48] <kjackal>     "bigtop_repo-x86_64": "https://ci.bigtop.apache.org/job/Bigtop-trunk/BUILD_ENVIRONMENTS%3Dubuntu-14.04,label%3Ddocker-slave/lastSuccessfulBuild/artifact/output/apt/"
[08:48] <admcleod> kjackal: where are those values?
[08:48] <admcleod> kjackal: in which file
[08:49] <kjackal> these are config variables of the bigtop-base layer
[08:49] <kjackal> so they have to be set at the layer.yaml of your charm
[08:50] <kjackal> It would be nice if we had the option of setting them ad deployment time
[08:50] <kjackal> right now they have to be set at build time
[08:51] <kjackal> admcleod: there is something else to be aware of. The patches under resources inside the bigtop base have now been grouped per release
[08:51] <admcleod> kjackal: i see. ok, thanks
[08:52] <kjackal> for master the directory is bigtop.master
[08:53] <kjackal> the idea is as soon as 1.2.0 release is out we should move all patches to a new directory re build our charms and publish them again
[08:54] <kjackal> there is a titcket+email that describes the situation
[08:54] <admcleod> kjackal: yes im aware of that, thanks
[09:12] <eeemil_> I'm new to Juju. I'm trying to deploy openstack-base. When I'm trying to deploy using the GUI, an error occurs instantly: 'The following errors occurred while retrieving bundle changes: unknown object type "ChangeSet"' and nothing happens.
[09:12] <eeemil_> When trying with the CLI, stuff seems to be deploying properly when inspected through "juju status" (however, the GUI doesnt show that anything has been deployed). Things however seems to get stuck though on that Keystone-unit won't recognize its Database-connection.
[09:12] <eeemil_> Anybody knows where I should start to diagnose stuff? Shouldn't the services deployed through CLI show up in the GUI?
[09:14] <eeemil_> I'm deploying on AWS by the way.
[10:08] <babbageclunk> eeemil_: It sounds like there's a version mismatch between the GUI and the version of juju you're running. What beta are you on?
[10:10] <babbageclunk> eeemil_: Are you on the mailing list? There was an API change recently that would cause this.
[10:10] <babbageclunk> eeemil_: https://lists.ubuntu.com/archives/juju/2016-July/007505.html
[10:11] <babbageclunk> eeemil_: That has instructions to upgrade the GUI so it'll work with the new API..
[10:14] <eeemil_> I'll look into it, I'm not on the mailing list but have subscribed now!
[10:15] <babbageclunk> eeemil_: As far as the keystone unit not connecting to the database - maybe try looking in the logs? "juju debug-log --replay"
[10:21] <eeemil_> Ahh, wasnt aware of the --replay-flag. Thanks! I'll look into it further. Do you know of any more helpful commands for debugging charms? I tried SSH:ing to the machines but couldnt find much of use.
[10:22] <magicaltrout> you can look at the log on the charm itself in /var/log/juju as well
[10:22] <magicaltrout> but its identical to the replay log, so you won't see much else :)
[10:22] <magicaltrout> of course ssh'ing when you have an error does allow you to double check configuration settings etc manually
[10:23] <magicaltrout> also you can do stuff like juju run --unit dcos-master9/0 "hooks/install" to forcibly re-run a hook
[10:25] <eeemil_> Yeah, the juju run-command seems really helpful, I didn't know you could force-run a hook like that!
[10:35] <eeemil_> By the way, babbageclunk: the newer juju gui version did the trick, I can now see everything through the gui! :)
[10:35] <babbageclunk> eeemil_: Great!
[10:55] <kjackal> SaMnCo: admcleod: Michael replied and he seemed realy eager to work with us. Are you interested in talking with him? Do you have any time constraints?
[10:58] <admcleod> kjackal: sure
[11:49] <SaMnCo> Not after 5PM please, got people at home after that
[11:49] <SaMnCo> Otherwise my calendar is up to date
[12:10] <SaMnCo> kjackal: ^
[12:23] <kjackal> Ok SaMnCo, thanks
[14:42] <jamespage> marcoceppi, https://code.launchpad.net/~james-page/charm-helpers/apache-2.0/+merge/299320
[14:47] <jamespage> marcoceppi, that was quick
[14:47] <marcoceppi> jamespage: lgtm
[14:57] <marcoceppi> jamespage: do you forsee major issues with moving charmhelpers to gh? I know it'd be an undertaking, and we'd have to setup lp to mirror gh for legacy - curious your opinion
[15:09] <jamespage> marcoceppi, +1
[15:13] <jcastro> admcleod: heya
[15:13] <jcastro> are you guys going to submit to big data spain
[15:13] <jcastro> http://www.bigdataspain.org/
[15:14] <marcoceppi> jamespage: cool, I'll take a stab at initial migration later this week
[16:21] <geetha> Hi, when I deploy my charm in juju 2.0 and try to change default value for config opion using juju set-config, config-changed hook is triggering but config.changed.<option> state is not set.
[16:27] <geetha> Hi, when I deploy my charm using juju 2.0 and try to change default value for config option using `juju set-config` command, config-changed hook is triggering but config.changed.<option> state has not set. Can any one please suggest me on this?
=== frankban is now known as frankban|afk
=== stub` is now known as stub
[16:46] <cory_fu> kwmonroe, petevg, admcleod, kjackal: I don't know if you guys saw the thread on the juju-dev mailing list about automatic hook retries, but we should get in the habbit of using `juju set-model-config automatically-retry-hooks=false` when doing our testing to help us spot any hook failures that go away on the retry (I know that came up at least once in the Bigtop charms).
[16:47] <cory_fu> (Note: that's a 2.0 command)
[16:47] <petevg> cory_fu: roger that.
[16:48] <kjackal> cory_fu: ack!
[16:48] <mgz> cory_fu: that seems reasonable to me.
[16:49] <cory_fu> If anyone was interested in the thread, it starts with https://lists.ubuntu.com/archives/juju-dev/2016-June/005714.html
=== dpm is now known as dpm-afk
=== gnuoy is now known as jamespage_shadow
=== jamespage_shadow is now known as gnuoy
=== gnuoy is now known as jamespage_shadow
=== jamespage_shadow is now known as gnuoy
=== gnuoy is now known as jamespage_shadow
[17:30] <bdx> openstack-charmers: hey whats up guys? I know, I just missed the openstack meeting, which is where I was hopping to bring these up ... but I have a few usablility concerns I wanted to get some input on if you don't mind
=== jamespage_shadow is now known as gnuoy
[17:32] <mskalka> marcoceppi, I'm adding some functionality to cholcombe's Juju crate and a question came up: Does the relation-ids function work outside of a relation hook? If so, would you just have to specify the relation identifier?
=== gnuoy is now known as jamespage_shadow
=== jamespage_shadow is now known as gnuoy
=== gnuoy is now known as jamespage_shadow
=== jamespage_shadow is now known as gnuoy
[21:01] <rick_h_> cherylj: do you know if anyone's around for your team's sync this week?
[21:02] <cherylj> rick_h_: for the core leads call?  I seriously doubt it
[21:03] <rick_h_> cherylj: more for the current "let's chat with rick_h_" call but yea
[21:03] <cherylj> tim's out, ian's out, alexis is out, menno is out
[21:03] <cherylj> oh
[21:03] <rick_h_> ok, will just kill off then
[21:03] <cherylj> yeah, I'm more certain about that one
[22:43] <cholcombe> rick_h_, are there any plans for cross controller relations?  Say for example aws east and aws west juju controllers talking to one another?
[22:46] <magicaltrout> yes cholcombe
[22:46] <magicaltrout> and cross providers
[22:46] <cholcombe> magicaltrout, oh man that's awesome!
[22:46] <magicaltrout> (i'm only saying yes because I asked the same a few times)
[22:46] <cholcombe> magicaltrout, is there a roadmap for that?
[22:46] <magicaltrout> dunno, it cropped up on the mailing list a few times
[22:46] <cholcombe> getting ceph radosgw to federate properly kinda needs it
[22:47] <magicaltrout> I used the monitoring problem as a good explaination, if I want to monitor my services, I don't really want my monitoring on the same infrastructure
[22:47] <cholcombe> yeah that's a good example
[22:47] <magicaltrout> or if I have a bunch of models, I also don't want them all to have their own monitoring
[22:47] <magicaltrout> I want a central service my models can relate to
[22:48] <cholcombe> yeah i think that would be really helpful to have