[03:48] OK, I'm feeling very dumb today. I'm working on a layered DNS charm (inspired by lazyPower's previous DNS work), but I'm still having the problem I described at http://irclogs.ubuntu.com/2016/05/23/%23juju.html [03:48] stub set me straight a while back about the need to call the basic layer from all hooks in order to get the config.set.* states, but they're still executing in a rather unexpected manner. [03:49] Code is at https://git.launchpad.net/~paulgear/charms/+source/layer-dynect/tree/reactive/dynect_provider.py - the methods on lines 70 & 96 both execute during the same hook, even though they're opposites. :-( [03:49] Any ideas on why? [03:50] Code it depends on (but is not terribly relevant here) is at https://git.launchpad.net/~paulgear/charms/+source/layer-dns/tree/reactive/dns_auto.py [03:51] And here's the log from the unit in question: http://pastebin.ubuntu.com/17283348/ [03:51] Any pointers greatly appreciated === frankban|afk is now known as frankban === zerick_ is now known as zerick [09:14] hi! [09:14] i get an error from some nodes "update-status" hook failed [09:15] resolve or retry does not solve it [09:15] do you know anything that I can do? or where to look whats going on? [09:16] manolos: that depends on the charm itself; check out the logs for it in /var/log/juju/unit-* [09:17] ok I will check there, love you bro [09:17] <3 [09:36] blahdeblah: I'd try breaking the when_all and when_not_all decorators into several @when and @when_not statements. You might have found a bug in the new @when_all and @when_not_all shortcuts (or maybe @when_not_all doesn't work that way - is it when none of the states are set, or is it when one of the states is not set?) [09:37] stub: according to doc, when_not_all == when not all of the states are set; when_none == when all of the states are not set [09:41] I can parse that first one two ways [09:42] stub: It's when any one (or more) of the states is not set. [10:18] Hi all, I'm trying to write a simple charm in juju 2.0 beta 8 on Xenial and when I run `charm build`, it crashes the terminal window: any idea how I can find out what's going wrong? === julenlar is now known as julenl === admcleod_ is now known as admcleod [11:48] stub: I did some more experimenting, and I've come to the conclusion that the config.set.* states are just not terribly useful. I couldn't split up the conditions, because that would turn the semantics of @when_not_all into @when_none, which is not appropriate in this instance. [11:49] stub: I decided to just go back to the solution I used when lazyPower & I discussed this previously: checking config items @when('config.changed'), and setting a single reactive to indicate that config is ready. [11:49] *single reactive state [12:43] gnuoy, time for a quick question? [12:43] tinwood, sure [12:43] gnuoy, shall we do it here or in #openstack-charmers? [12:43] tinwood, I didn't realise that was athing! [12:44] beisner set it up and there's a few there now. [12:44] gnuoy, I guess, probably here for now. [12:44] tinwood, I seem to be alone in there [12:45] apologies - #openstack-charms [12:45] gnuoy, ^^^ [12:45] k [12:49] *joins too* [15:11] marcoceppi: jcastro: hey, I was talking to someone from Linode yesterday about Juju, and he said they've got a new API coming out that might allow a Juju backend to bring up/down instances on their cloud, is anybody currently talking with them? [15:15] mhall119 I was talking to @FelicianoTech ~ this time last year [15:16] (twitter handle above ^) [15:16] mhall119: there's sales folks that interact with linode, but not sure if they're looking at this new api/etc [15:16] looks like they moved though :( no longer with linode [15:16] so thats a dead end [15:16] mhall119: worth an email to Udi or such to put it on their radar, especially with a contact/etc. [15:17] rick_h_: will send that out, thanks [15:27] kwmonroe, cory_fu, admcleod, petevg: I will have to update the hadoop-client we have on bigdata-dev because mahout adds an interface to that [15:28] kjackal: Why does Mahout add an interface to hadoop-client? [15:31] mahout is a library that sits on your client. When you submit a job that uses mahout the mahout jars get packaged [15:31] cory_fu: ^ [15:34] cory_fu: as a consiquence anyone that uses the hadoop-client layer can relate to mahout [16:27] just realized that a bad file in the apt/sources.list.d can break bootstrapping [16:32] cholcombe: ? how did you do that? [16:32] cholcombe: this is juju bootstrap? off an image? [16:33] rick_h_, i'm on my desktop and i had a bad entry in the sources.list.d that wouldn't download [16:33] and it sent bootstrap into an endless loop where it try to apt-get update [16:33] with the manual provider === firl_ is now known as firl [16:51] seems juju can't bootstrap raspberry pi 3's. The lxc containers fail to start [16:51] it can add them as a machine but i can't deploy anything [16:52] looks like it fails to load the seccomp policy and then blows up [16:53] anyone else tried using raspberry pi's as machines? [16:53] can a reactive state have punctuation (specifically underscores) in it? [17:04] cholcombe - i haven't in a while, i know that mattyw has done a lot of work there. he released a poc juju snap [17:05] admcleod - yep, leadership.is_leader as an example [17:07] lazyPower: oh yeah - thanks :) [17:13] * lazyPower hattips [17:23] lazyPower, yeah i saw his blog [17:26] cory_fu: when i push a bigdata charm that's going to be promulgated, i push to u/bigdata-charmers/trusty/X, and promulgate that.. so stuff like charm show always shows bigdata-charmers in the id. [17:26] cory_fu: but i see these are different: [17:27] charm show cs:~bigdata-charmers/trusty/apache-hadoop-namenode id revision-info [17:27] charm show cs:trusty/apache-hadoop-namenode id revision-info [17:27] the difference being the ~bigdata-charmers in the charm id [17:27] kwmonroe: Yeah. For reference, here's the output: http://pastebin.ubuntu.com/17298727/ [17:27] so why does the un-namespaced charm have extra revisions? [17:29] So, I'm not entirely certain, but I think that promulgation is not a plain reference like channels are. It seems to be its own entity, with its own revision history, which contains a channel-like pointer to another entity [17:30] Consider the case where a charm foo is promulgated from the namespace ~user-a [17:30] User-a no longer wants to maintain it and now User-b does. So, we unpromulgate ~user-a/foo and promulgate ~user-b/foo [17:30] But we don't want the revisions for cs:foo to reset [17:30] kwmonroe: regarding the flume-syslog, the change is in jujubigdata library, the 6.4.1 does not have the patch [17:31] ah, ok, that makes sense [17:31] let me verify that the two revisions i gave you are correct, just a sec [17:31] So instead cs:foo just gets another rev on its own list of revs that says "now point to cs:~user-b/foo" [17:31] I should have included revnos in that example [17:33] Maybe we need a section for explaining promulgation in https://jujucharms.com/docs/devel/authors-charm-store [17:33] +1 kjackal, they're legit. i just lapsed on the purpose of those updates -- for net restricted envs, you're right, everybody needs a later jujubigdata [17:33] Cool [17:34] Now rearding the spotlight in the blog [17:34] cory_fu: so is it safe to assume that the promulgated cs:trusty/apache-hadoop-namenode-2 is probably cs:~bigdata-charmers/trusty/apache-hadoop-namenode-1? [17:34] * kwmonroe fetches to check [17:35] kwmonroe, cory_fu, admcleod regarding George (last line in the blog). George is the head of IT in the lab, mentioned inside the text [17:35] We are friends, yes [17:35] kwmonroe: It's not same to assume, but I think there's a "hash" field that we can use to verify [17:36] kjackal: both admcleod and i are +1 to drop that line. it could start a war we're not ready to fight. [17:37] I thought it is good to poke the IT head(s) to start offering Juju [17:37] yup cory_fu, that's way better (hash256) [17:37] what kind of war? [17:37] kwmonroe: http://pastebin.ubuntu.com/17299258/ [17:38] LGTM [17:38] see what happened there kjackal? i was joking about a war but you didn't catch it. just drop the line so i can sleep better. [17:41] cool cory_fu [17:41] Ah if it is for your sleep I will defentely remove the line [17:41] I think I'm going to make an alias for that [17:41] that beats my current workflow of 'charm pull' x2 and 'diff -pur' [17:41] lol, thx kjackal ;) [17:41] kwmonroe: Maybe we should open an issue somewhere to see what namespace a promulgated charm is pointing to, in the output of `charm show` [17:41] that's a nice idea cory_fu.. what do you call that entity? the source? [17:41] no idea. They must have an internal name for it. [17:42] I don't even know where to report that issue. I guess https://github.com/juju/charmstore/issues maybe? [17:43] kwmonroe: Looks like stub beat us to it: https://github.com/juju/charmstore/issues/631 [17:44] nice - if only i could turn up the heat on that. lp ftw. [17:44] thumb < flame [17:49] kwmonroe, cory_fu, admcleod, petevg: how do we publish blogs? is there a project/wiki we edit? [17:49] kjackal: checkout the gh-pages of this repo: https://github.com/juju-solutions/bigdata-community/tree/gh-pages [17:50] add your markdown to _posts [17:50] kwmonroe: great thank, I will have it ready by the end of the day [17:51] kjackal: you can add it to a local _drafts dir if you want to serve/verify locally before publishing it to _posts. [17:57] cory_fu: this is a pickle for apache-based bundles: https://github.com/juju-solutions/layer-hadoop-client/commit/995a21f5149a36182dfb6eec59dfd4b52abfef38 this came in between hadoop-client-3 and -4. need to make sure apache bundles stay on 3 or include openjdk if we need > 3 in the future. [17:58] Hrm. :/ [18:00] Well, it wouldn't be difficult to add openjdk for the client, right? I wonder if it's worth the effort to go back and add support for the java interface to the apache charms? [18:04] no, it wouldn't be difficult. no, i don't think it's worth the effort until we need a newer hadoop-client. currently, v4 only adds java, so no harm in v3 imho. [18:06] kwmonroe: The only issue with that is that hadoop-client is also the base layer for some of the apache charms, like apache-spark [18:06] So we may run in to it if any of those need to be updated [18:17] that sounds like some far off magical bridge. i'm sure future big data team members will have no trouble crossing it. [18:17] :) [20:27] kwmonroe, cory_fu: I have this PR for the blog post https://github.com/juju-solutions/bigdata-community/pull/7 [20:27] should I merge it? [20:32] kjackal: is this the thing you deployed? http://svg.juju.solutions/?bundle=cs:bundle/apache-processing-mapreduce-2 [20:32] kjackal: i think it would be nice to put an svg of whatever bundle they used somewhere around the "Deploying a mapreduce processing bundle" sentence towards the end. [20:34] kjackal: it's getting super late for you -- i don't think there's a rush to get this out this afternoon, and i think a pic would be nice to show the bundle they used. [20:34] we used one of the old bundles (hadoop-processing-core) [20:34] work, the greek economy depends on you! [20:35] heh [20:35] We had the same problem with the paper as well, they were referencing a bundle that is depricated now, so we had to change the reference to point to our landing page [20:36] magicaltrout: you have no idea how true this is! [20:36] Hey, can someone think of a good, non-big data example charm to point Roman to that demonstrates handling scaling the service up and down? [20:36] Ideally one that's using reactive, but I'd be fine w/ a non-reactive charm too [20:36] Apache Drill :P [20:36] :) [20:37] non, bigdat and easy, mediawiki ? [20:37] or some mysql-esque charm must scale sanely? [20:38] he deals with databases enough [20:42] Actually, I guess petevg you should just link him to the handler and lib function in your branch. :) [20:42] cory_fu: yeah. Just working on doing that. :-) === natefinch is now known as natefinch-afk