| 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:48 |
| 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:49 |
| 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:50 |
| blahdeblah | And here's the log from the unit in question: http://pastebin.ubuntu.com/17283348/ | 03:51 |
| blahdeblah | Any pointers greatly appreciated | 03:51 |
| === frankban|afk is now known as frankban | ||
| === zerick_ is now known as zerick | ||
| manolos | hi! | 09:14 |
| manolos | i get an error from some nodes "update-status" hook failed | 09:14 |
| 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:15 |
| blahdeblah | manolos: that depends on the charm itself; check out the logs for it in /var/log/juju/unit-* | 09:16 |
| manolos | ok I will check there, love you bro | 09:17 |
| manolos | <3 | 09:17 |
| 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:36 |
| 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:37 |
| stub | I can parse that first one two ways | 09:41 |
| blahdeblah | stub: It's when any one (or more) of the states is not set. | 09:42 |
| 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? | 10:18 |
| === julenlar is now known as julenl | ||
| === admcleod_ is now known as admcleod | ||
| 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:48 |
| 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 | 11:49 |
| 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:43 |
| 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:44 |
| tinwood | apologies - #openstack-charms | 12:45 |
| tinwood | gnuoy, ^^^ | 12:45 |
| gnuoy | k | 12:45 |
| xilet | *joins too* | 12:49 |
| 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:11 |
| lazyPower | mhall119 I was talking to @FelicianoTech ~ this time last year | 15:15 |
| 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:16 |
| mhall119 | rick_h_: will send that out, thanks | 15:17 |
| 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:27 |
| cory_fu | kjackal: Why does Mahout add an interface to hadoop-client? | 15:28 |
| 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:31 |
| kjackal | cory_fu: as a consiquence anyone that uses the hadoop-client layer can relate to mahout | 15:34 |
| cholcombe | just realized that a bad file in the apt/sources.list.d can break bootstrapping | 16:27 |
| rick_h_ | cholcombe: ? how did you do that? | 16:32 |
| rick_h_ | cholcombe: this is juju bootstrap? off an image? | 16:32 |
| 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:33 |
| === firl_ is now known as firl | ||
| 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:51 |
| cholcombe | looks like it fails to load the seccomp policy and then blows up | 16:52 |
| cholcombe | anyone else tried using raspberry pi's as machines? | 16:53 |
| admcleod | can a reactive state have punctuation (specifically underscores) in it? | 16:53 |
| 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:04 |
| lazyPower | admcleod - yep, leadership.is_leader as an example | 17:05 |
| admcleod | lazyPower: oh yeah - thanks :) | 17:07 |
| * lazyPower hattips | 17:13 | |
| cholcombe | lazyPower, yeah i saw his blog | 17:23 |
| 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:26 |
| 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:27 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:33 |
| 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:34 | |
| 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:35 |
| kwmonroe | kjackal: both admcleod and i are +1 to drop that line. it could start a war we're not ready to fight. | 17:36 |
| 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:37 |
| 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:38 |
| 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:41 |
| cory_fu | I don't even know where to report that issue. I guess https://github.com/juju/charmstore/issues maybe? | 17:42 |
| cory_fu | kwmonroe: Looks like stub beat us to it: https://github.com/juju/charmstore/issues/631 | 17:43 |
| kwmonroe | nice - if only i could turn up the heat on that. lp ftw. | 17:44 |
| kwmonroe | thumb < flame | 17:44 |
| 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:49 |
| kwmonroe | add your markdown to _posts | 17:50 |
| kjackal | kwmonroe: great thank, I will have it ready by the end of the day | 17:50 |
| kwmonroe | kjackal: you can add it to a local _drafts dir if you want to serve/verify locally before publishing it to _posts. | 17:51 |
| 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:57 |
| cory_fu | Hrm. :/ | 17:58 |
| 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:00 |
| 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:04 |
| 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:06 |
| 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 | :) | 18:17 |
| 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:27 |
| 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:32 |
| 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:34 |
| 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:35 |
| 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:36 |
| kjackal | non, bigdat and easy, mediawiki ? | 20:37 |
| magicaltrout | or some mysql-esque charm must scale sanely? | 20:37 |
| magicaltrout | he deals with databases enough | 20:38 |
| 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. :-) | 20:42 |
| === natefinch is now known as natefinch-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!