=== thumper is now known as thumper-dogwalk === natefinch-afk is now known as natefinch === thumper-dogwalk is now known as thumper === rogpeppe2 is now known as rogpeppe === jam1 is now known as jam === Guest51132 is now known as med_ === valeech_ is now known as valeech [15:59] How can I debug why a juju run is not completing? [16:08] kwmonroe: here's the traceback I get when trying to deploy a xenial version of the zookeeper charm: http://paste.ubuntu.com/21019611/ [16:08] It looks like it is a failure in the openjdk layer; it's looking for /etc/default/bigtop-utils, but that doesn't exist ... [16:10] petevg: that ain't nary an openjdk layer failure.. openjdk doesn't need bigtop-utils. it's gotta be a failure of zookeeper or the bigtop base layer. [16:11] Hmmm ... Zookeeper doesn't attempt to edit anything in place, though. [16:11] ... I think. [16:11] yeah, it's coming from lib/charms/layer/apache_ [16:11] bigtop_base.py", line 239, in trigger_puppet [16:12] x58 - you can juju debug-hooks application/# which will put you in an interactive shell (just a plain ol root shell by default) [16:12] it should trap that run stanza and give you an opportunity to debug [16:13] petevg: i might have spoken too soon -- there is some java stuff that it's looking for during that re_edit_in_place.. i'll kick it around in just a few minutes. [16:13] kwmonroe: here's my branch, for reference: https://github.com/juju-solutions/bigtop/tree/zookeeper-bind-address [16:13] cool, thx petevg [16:13] Did I specify the series correctly in metadata.yaml? [16:14] yeah petevg -- that looks legit [16:14] lazypower: Thans. [16:14] kwmonroe: you're right about where it's coming from. Here's the line from the base layer: [16:15] http://paste.ubuntu.com/21020508/ [16:15] kwmonroe: do we have any big data charms that we've actually deployed/tested on xenial? [16:15] ah, right petevg.. so the question is now why isn't /etc/default/bigtop-utils present? is zk trying to trigger_puppet before bigtop-base is available? [16:18] kwmonroe: Hmmm. Bigtop looks like it installed -- there's a bigtop.release directory in the ubuntu user's home dir. [16:18] etc/default/bigtop-utils isn't there, though. [16:20] petevg: could it be the zookeeper deb in bigtop's repo doesn't correctly specify bigtop-utils as a prereq? said differently, how does bigtop-utils get installed with a trusty deployment? i don't see us specifically calling that out in the bigtop base layer. [16:20] kwmonroe: That sounds plausible (I don't see it explicitly installing it, either.) [16:22] kwmonroe: Yeah. If I apt install "bigtop-utils" and then run "juju resolved zookeeper/0", everything looks happier. [16:22] I think that I'm going to go ahead and cheat and just explicitly call "apt install bigtop-utils" in the charm for now, to get this done. I'll file a ticket w/ bigtop to get the package fixed. [16:24] roger that petevg.. perhaps we can also work around with an explicit bigtop-utils entry in the base layer: https://github.com/juju-solutions/layer-apache-bigtop-base/blob/master/layer.yaml#L7 [17:25] Hi [17:26] I am getting the following error when I deploy the charm http://pastebin.ubuntu.com/21028721/ [17:26] and the juju status shows as "message: agent is lost, sorry! See 'juju status-history websphere-liberty/0'" [17:27] Can anyone help me with this ? [17:28] juju status history shows this : http://pastebin.ubuntu.com/21028908/ === fginther` is now known as fginther [17:39] suchvenu: it seems anastasia suggested trying juju-1.25.6 in bug 1465307, but i do not see that as released yet. [17:39] Bug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages

[17:39] anyone know when 1.25.6 is due? [17:40] kwmonroe - its in proposed [17:40] add-apt-repository ppa:juju/proposed [17:42] ah, ack lazypower.. suchvenu if you want to try the proposed 1.25.6, do: [17:42] sudo add-apt-repository ppa:juju/proposed && sudo apt update && sudo apt upgrade juju [17:43] ok kwmonroe [18:07] anyone knows how to connect juju to openstack (deployed through juju) i tried this URL https://blog.felipe-alfaro.com/2014/04/29/bootstraping-juju-on-top-of-an-openstack-private-cloud/ [18:07] but facing issues [18:11] narindergupta - what issues are you encountering? [18:12] narindergupta - we use juju driving a juju deployed openstack all the time internally with OIL and other efforts [18:12] lazypower, juju.cmd supercommand.go:429 failed to bootstrap environment: index file has no data for cloud {RegionOne http://10.5.1.83:35357/v2.0} not found [18:12] ahh i have seen this before but i dont recall the fix... one sec while I see if i can get someone to lend a hand. [18:13] lazypower, sure will be helpful. Also if you have the clear method explaining or script will be helpful? [18:13] narindergupta - i think you have to build simplestreams, but i'm verifying that [18:14] lazypower, how to do that? [18:14] i very well could be wrong, adn we have a lot of high profile folks out at the mid cycle sprint, so i may redirect you to the juju mailing list allowing them a chance to chime in [18:15] lazypower, zahra already posted this to mailing list. everyone says juju can not connect to cloud but manually i can do everything to cloud [18:15] lazypower, but any information will be helpful [18:15] you bet, i'll do what i can to help. i've got your contact details, i'll e-mail you any information i can surface today [18:16] lazypower, sounds good to me thanks [18:32] make it work lazypower ! [18:33] magicaltrout - working on it, its hard to do when there's no response from the SME's ;) [18:33] hehe [18:35] kwmonroe: Hmmm ... looks like bigdata-utils being missing might be just the tip of the iceberg for Zookeeper on xenial. It looks like the Zookeeper xenial deb installs it in /usr/share/zookeeper rather than /usr/lib/zookeeper, and that screws up the puppet scripts :-/ [18:38] petevg: how are you specifying the xenial deb in your zk layer? [18:39] kwmonroe: I'm not. I'm just running puppet and letting it do its thing. [18:39] petevg: did you alter the bigtop_repo_x86 layer opt? or manually apt-add-repo? [18:39] Currently digging through puppet stuff to see if I can override the path ... I see a lot of instances of that zookeeper path being a defaul or hardcoded, though. [18:39] kwmonroe: again. Not doing anything manually. Just telling bigtop to do its thing. [18:40] petevg: i bet i know what's happening.. i bet there's a zookeeper package in the xenial archives. on the borked system, what does "dpkg -l | grep zoo" say? [18:42] kwmonroe: http://paste.ubuntu.com/21038468/ [18:42] petevg: how about "sudo apt-cache madison zookeeper" [18:43] kwmonroe: http://paste.ubuntu.com/21038664/ [18:43] thar she be petevg [18:43] So there is a package in universe. [18:44] Yeah. And it's newer, so that's why it's being grabbed, right? [18:44] i'm not sure how the precedent is set [18:44] but your thought seems reasonable.. bigger version wins [18:45] so now petevg.. we need to figure out how to force the bigtop repo to win. maybe a priority option we can set? [18:45] kwmonroe: Probably. Do you know where puppet calls apt/dpkg? [18:46] We either need to do some magic before that runs, or override it. [18:48] I think that I want to pin the package. I'm not sure that it's going to be easy to do so before bigtop installs zookeeper, but after it adds its repo. Digging into it now ... === sidarta is now known as soliveira [19:37] ok petevg, let's compare notes.. http://paste.ubuntu.com/21045756/ [19:38] petevg: one solution is to create an /etc/apt/preferences.d/file to force bigtop repos to take priority (as seen in above paste) [19:39] kwmonroe: Yep. That's pretty much what I found. Need to test it and make sure that it works before the repo is actually setup. [19:45] kwmonroe: thx for suggesting the wildcard -- covering the same case elsewhere makes sense. [19:46] petevg: the pro is that presumably all zk deps would get prioritized too (or rather, all bigtop repo bits would). the con is that there may be some old crusty deb in the bigtop repo that we really didn't want to take prescendent over the main archive. [19:47] True. I think that the pro outweighs the con, though. [19:47] yeah, me too. lest you're stuck managing deps in a preferences file till you simply die. [19:47] I'm sticking the file in a resource, reading it into Python, then writing it out, so we can do some parsing if it every becomes a big problem. [19:48] word petevg. perhaps think about using the bigtop_repo layer option (from bigtop base layer) as the url to use in the origin matcher. it may not always be "bigtop-repos.s3.amazonaws.com". [19:49] kwmonroe: Good idea. Will do. [19:50] in fact, it probably should never be that hard coded string, but whatever the hostname for the repo url may be. surely there's some pythony thing to strip 'http://' and '/blah/foo' from a url and just leave the fqdn. [19:56] kwmonroe: bigtop_repo[7:].split("/")[0] should do it. Not pretty, but it works. :-) [19:57] its okay [19:57] kwmonroe hasn't written a pretty line of code in his life [19:57] petevg: it's gonna get uglier too.. the layer option is "bigtop_repo-$(arch)" [19:57] Yep. I'm in the middle of writing that section of code right now :-) [19:58] and petevg, what if somebody uses https or ftp? that'll dork the 7th char. [19:58] magicaltrout: all my code is handsome [19:58] This is why a lib is always nice :-) [19:58] hehe [19:59] dont we use urlparse in these bt charms? surely that would do a fine parsing job [19:59] urlparse [20:00] Here's an ugly function for you: http://paste.ubuntu.com/21048613/ (Going to test to verify that the approach works, and worry about making things prettier later.) [20:00] magicaltrout: if you can't keep up, at least keep quiet [20:00] *sob* [20:00] * magicaltrout finds more wine [20:00] ;) [20:01] magicaltrout: thank you. urlparse is a good idea, to catch other stuff I haven't thought of. [20:01] petevg: i like everything about that function except line 8 [20:02] that's like 92% approval from me [20:02] which is pretty incredible [20:02] Excellent. I'll fix up line 8 with urlparse before review :-p [20:02] :) +1 === natefinch is now known as natefinch-afk [20:17] kwmonroe: yay. Tests passed! Cleaning up code. PRs coming your way soon ... [20:33] juju run --service myserver hangs forever and never seems to complete. [20:36] kwmonroe: PRs for you: https://github.com/juju-solutions/bigtop/pull/30 lazyPower had volunteered to review them, so feel free to sling it over to him if you run short on time :-) [20:36] (That PR links to the other two.) [20:59] roger petevg, taking a gander ahora [21:36] Hey guys, what would you do if you'd need to deploy some none juju services on blank Ubuntu machines if you have an MAAS managed infra with some juju deployments already? Just commission machines in MAAS, use the ubuntu charm so you can manage it some what with juju and get some flexibility with lxd containers, or some other approach? [21:37] I see that the ubuntu charm is intended for testing and development, but is there anything inherently missing that I should look out for? [21:42] petevg: "This breaks many things" lol. zk and bigtop-base PRs merged. we'll let upstream marinate on their PR. [21:45] kwmonroe: Cool. Thank you :-) [21:48] zeestrat: deploying 'ubuntu' seems a fine way to do what you want. i don't know of anything missing that would make you say "oh, this is why it's test/dev only". it's just a cloud-init ubuntu installation. [21:49] zeestrat: and you do get the benefit of connecting stuff up to it.. anything that uses the juju-info relation can be attached to your 'ubuntu' charm units... stuff like ganglia for monitoring, etc [22:42] petevg: fwiw, https://jujucharms.com/u/bigdata-dev/zookeeper/xenial/1 is your new hotness [22:43] kwmonroe: sweet! Thank you :-) [22:44] not so fast petevg.. the bigtop_apt change in the zookeeper push now conflicts with your unit test PR :/ https://github.com/juju-solutions/layer-apache-bigtop-base/pull/28 [22:45] not a big deal, just wanted to knock you down a peg this fine tuesday afternoon ;) [22:45] kwmonroe: of course it does. Will fix it in the morning :-) [22:45] cool - thanks, and have a good night!