[03:48] <blahdeblah> 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] <blahdeblah> 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] <blahdeblah> 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] <blahdeblah> Any ideas on why?
[03:50] <blahdeblah> 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] <blahdeblah> And here's the log from the unit in question: http://pastebin.ubuntu.com/17283348/
[03:51] <blahdeblah> Any pointers greatly appreciated
[09:14] <manolos> hi!
[09:14] <manolos> i get an error from some nodes "update-status" hook failed
[09:15] <manolos> resolve or retry does not solve it
[09:15] <manolos> do you know anything that I can do? or where to look whats going on?
[09:16] <blahdeblah> manolos: that depends on the charm itself; check out the logs for it in /var/log/juju/unit-*
[09:17] <manolos> ok I will  check there, love you bro
[09:17] <manolos> <3
[09:36] <stub> 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] <blahdeblah> 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] <stub> I can parse that first one two ways
[09:42] <blahdeblah> stub: It's when any one (or more) of the states is not set.
[10:18] <brunogirin> 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?
[11:48] <blahdeblah> 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] <blahdeblah> 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] <blahdeblah> *single reactive state
[12:43] <tinwood> gnuoy, time for a quick question?
[12:43] <gnuoy> tinwood, sure
[12:43] <tinwood> gnuoy, shall we do it here or in #openstack-charmers?
[12:43] <gnuoy> tinwood, I didn't realise that was athing!
[12:44] <tinwood> beisner set it up and there's a few there now.
[12:44] <tinwood> gnuoy, I guess, probably here for now.
[12:44] <gnuoy> tinwood, I seem to be alone in there
[12:45] <tinwood> apologies - #openstack-charms
[12:45] <tinwood> gnuoy, ^^^
[12:45] <gnuoy> k
[12:49] <xilet> *joins too*
[15:11] <mhall119> 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] <lazyPower> mhall119 I was talking to @FelicianoTech ~ this time last year
[15:16] <lazyPower> (twitter handle above ^)
[15:16] <rick_h_> mhall119: there's sales folks that interact with linode, but not sure if they're looking at this new api/etc
[15:16] <lazyPower> looks like they moved though :( no longer with linode
[15:16] <lazyPower> so thats a dead end
[15:16] <rick_h_> mhall119: worth an email to Udi or such to put it on their radar, especially with a contact/etc.
[15:17] <mhall119> rick_h_: will send that out, thanks
[15:27] <kjackal> 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] <cory_fu> kjackal: Why does Mahout add an interface to hadoop-client?
[15:31] <kjackal> mahout is a library that sits on your client. When you submit a job that uses mahout the mahout jars get packaged
[15:31] <kjackal> cory_fu: ^
[15:34] <kjackal> cory_fu: as a consiquence anyone that uses the hadoop-client layer can relate to mahout
[16:27] <cholcombe> just realized that a bad file in the apt/sources.list.d can break bootstrapping
[16:32] <rick_h_> cholcombe: ? how did you do that?
[16:32] <rick_h_> cholcombe: this is juju bootstrap? off an image?
[16:33] <cholcombe> rick_h_, i'm on my desktop and i had a bad entry in the sources.list.d that wouldn't download
[16:33] <cholcombe> and it sent bootstrap into an endless loop where it try to apt-get update
[16:33] <cholcombe> with the manual provider
[16:51] <cholcombe> seems juju can't bootstrap raspberry pi 3's.  The lxc containers fail to start
[16:51] <cholcombe> it can add them as a machine but i can't deploy anything
[16:52] <cholcombe> looks like it fails to load the seccomp policy and then blows up
[16:53] <cholcombe> anyone else tried using raspberry pi's as machines?
[16:53] <admcleod> can a reactive state have punctuation (specifically underscores) in it?
[17:04] <lazyPower> 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] <lazyPower> admcleod - yep, leadership.is_leader as an example
[17:07] <admcleod> lazyPower: oh yeah - thanks :)
[17:13]  * lazyPower hattips
[17:23] <cholcombe> lazyPower, yeah i saw his blog
[17:26] <kwmonroe> 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] <kwmonroe> cory_fu: but i see these are different:
[17:27] <kwmonroe> charm show cs:~bigdata-charmers/trusty/apache-hadoop-namenode id revision-info
[17:27] <kwmonroe> charm show cs:trusty/apache-hadoop-namenode id revision-info
[17:27] <kwmonroe> the difference being the ~bigdata-charmers in the charm id
[17:27] <cory_fu> kwmonroe: Yeah.  For reference, here's the output: http://pastebin.ubuntu.com/17298727/
[17:27] <kwmonroe> so why does the un-namespaced charm have extra revisions?
[17:29] <cory_fu> 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] <cory_fu> Consider the case where a charm foo is promulgated from the namespace ~user-a
[17:30] <cory_fu> 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] <cory_fu> But we don't want the revisions for cs:foo to reset
[17:30] <kjackal> kwmonroe: regarding the flume-syslog, the change is in jujubigdata library, the 6.4.1 does not have the patch
[17:31] <kwmonroe> ah, ok, that makes sense
[17:31] <kjackal> let me verify that the two revisions i gave you are correct, just a sec
[17:31] <cory_fu> 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] <cory_fu> I should have included revnos in that example
[17:33] <cory_fu> Maybe we need a section for explaining promulgation in https://jujucharms.com/docs/devel/authors-charm-store
[17:33] <kwmonroe> +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] <kjackal> Cool
[17:34] <kjackal> Now rearding the spotlight in the blog
[17:34] <kwmonroe> 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] <kjackal> 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] <kjackal> We are friends, yes
[17:35] <cory_fu> kwmonroe: It's not same to assume, but I think there's a "hash" field that we can use to verify
[17:36] <kwmonroe> kjackal: both admcleod and i are +1 to drop that line.  it could start a war we're not ready to fight.
[17:37] <kjackal> I thought it is good to poke the IT head(s) to start offering Juju
[17:37] <kwmonroe> yup cory_fu, that's way better (hash256)
[17:37] <kjackal> what kind of war?
[17:37] <cory_fu> kwmonroe: http://pastebin.ubuntu.com/17299258/
[17:38] <cory_fu> LGTM
[17:38] <kwmonroe> 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] <kwmonroe> cool cory_fu
[17:41] <kjackal> Ah if it is for your sleep I will defentely remove the line
[17:41] <cory_fu> I think I'm going to make an alias for that
[17:41] <kwmonroe> that beats my current workflow of 'charm pull' x2 and 'diff -pur'
[17:41] <kwmonroe> lol, thx kjackal ;)
[17:41] <cory_fu> 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] <kwmonroe> that's a nice idea cory_fu.. what do you call that entity?  the source?
[17:41] <cory_fu> no idea.  They must have an internal name for it.
[17:42] <cory_fu> I don't even know where to report that issue.  I guess https://github.com/juju/charmstore/issues maybe?
[17:43] <cory_fu> kwmonroe: Looks like stub beat us to it: https://github.com/juju/charmstore/issues/631
[17:44] <kwmonroe> nice - if only i could turn up the heat on that.  lp ftw.
[17:44] <kwmonroe> thumb < flame
[17:49] <kjackal> kwmonroe, cory_fu, admcleod, petevg: how do we publish blogs? is there a project/wiki we edit?
[17:49] <kwmonroe> kjackal: checkout the gh-pages of this repo: https://github.com/juju-solutions/bigdata-community/tree/gh-pages
[17:50] <kwmonroe> add your markdown to _posts
[17:50] <kjackal> kwmonroe: great thank, I will have it ready by the end of the day
[17:51] <kwmonroe> kjackal: you can add it to a local _drafts dir if you want to serve/verify locally before publishing it to _posts.
[17:57] <kwmonroe> 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] <cory_fu> Hrm.  :/
[18:00] <cory_fu> 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] <kwmonroe> 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] <cory_fu> 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] <cory_fu> So we may run in to it if any of those need to be updated
[18:17] <kwmonroe> that sounds like some far off magical bridge.  i'm sure future big data team members will have no trouble crossing it.
[18:17] <cory_fu> :)
[20:27] <kjackal> kwmonroe, cory_fu: I have this PR for the blog post https://github.com/juju-solutions/bigdata-community/pull/7
[20:27] <kjackal> should I merge it?
[20:32] <kwmonroe> kjackal: is this the thing you deployed? http://svg.juju.solutions/?bundle=cs:bundle/apache-processing-mapreduce-2
[20:32] <kwmonroe> 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] <kwmonroe> 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] <kjackal> we used one of the old bundles (hadoop-processing-core)
[20:34] <magicaltrout> work, the greek economy depends on you!
[20:35] <kwmonroe> heh
[20:35] <kjackal> 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] <kjackal> magicaltrout: you have no idea how true this is!
[20:36] <cory_fu> 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] <cory_fu> Ideally one that's using reactive, but I'd be fine w/ a non-reactive charm too
[20:36] <magicaltrout> Apache Drill :P
[20:36] <cory_fu> :)
[20:37] <kjackal> non, bigdat and easy, mediawiki ?
[20:37] <magicaltrout> or some mysql-esque charm must scale sanely?
[20:38] <magicaltrout> he deals with databases enough
[20:42] <cory_fu> Actually, I guess petevg you should just link him to the handler and lib function in your branch.  :)
[20:42] <petevg> cory_fu: yeah. Just working on doing that. :-)