[02:12] <petevg> cory_fu: that bug you're running into is probably my fault. Was going to test some code more thoroughly and push in the morning, but take a look at https://github.com/petevg/python-libjuju/tree/bug/fixes-for-null-cases
[02:14] <cory_fu> petevg: I think preventing the crashes on our end is good, but that controller panic definitely shouldn't happen
[02:14] <petevg> True.
[02:15] <cory_fu> petevg: Also, there's some overlap with your branch and a PR I got in this evening: https://github.com/juju/python-libjuju/pull/24
[02:15] <petevg> cory_fu: I may also be wrong about it being my fault. Those fixes don't actually change anything (just ran a matrix test) :-/
[02:16] <cory_fu> petevg: Yeah, the directive change doesn't fix the controller panic.  I think we must be passing something in to the API as a None that it expects to have a value
[02:17] <petevg> Lovely.
[02:17] <cory_fu> petevg: If you look at the panic log that I included, you can see which params are null (0x00) and compare that to the code signature to work backwards to what we should be passing
[02:17] <cory_fu> But it's not going to be fun
[02:18] <cory_fu> Anyway, I'm done for the evening.  We can pair on it tomorrow, if you want.  Have a good night!
[02:20] <petevg> cory_fu: sounds good. You have a good night, too (undoing my placement fix fixes things, btw, so it is something to do with the Placement object.)
[02:26] <petevg> cory_fu: this works, btw `placement=[parse_placement(to)] if to else None`, for wiki-simple, and for hadoop-processing. I want to do some more banging on it before I check that in, though ... (for now, to bed for me)
[05:42] <wxl> is `juju set` not actually a thing? can't find it in the manpage and i get an error trying to run it in a fresh zesty server. and yet: https://jujucharms.com/wordpress/trusty/4
[06:30] <zeestrat> wxl: It's 'juju config' in Juju 2.0
[12:09] <anita> Hi
[12:10] <Guest5875> how to get the values from config.yaml file in juju 2.0. I searched and found config=hookenv.config(). then config.get('parameter'). but when I am giving as "juju config <service> paramter=value" its not accepting.
[12:11] <Guest5875> is it correct?
[12:16] <marcoceppi> Guest5875: everything you've mentioned is correct
[12:16] <marcoceppi> Guest5875: maybe a look at your charm code would be helpful
[12:18] <Guest5875> marcoceppi_:ok, thanks a lot
[12:43] <BlackDex> hello there
[12:44] <BlackDex> I have an error "Incomplete relations: identity"
[12:44] <BlackDex> on all units of the same service
[12:44] <BlackDex> glance in this case
[12:44] <BlackDex> i tried to remove it and add it again, but it doesn't seem to work
[12:51] <marcoceppi> BlackDex: can you put the output of juju status into paste.ubuntu.com and share the link?
[12:59] <BlackDex> one moment
[13:01] <BlackDex> marcoceppi: http://paste.ubuntu.com/23557948/
[13:05] <marcoceppi> BlackDex: so a few things, are you locked into 1.25? 2.0 has been out for a little over a month, second, there seems to be a few things still churning, finally you might get better assitance in #openstack-charms since this is really an openstack setup question
[13:09] <BlackDex> i'm locked to 1.25 for now
[13:20] <SimonKLB> is there a relation, similar to the special juju-info one for subordinate charms, which can be used with more or less every charm when the goal is simply to get the name of the related charm?
[13:20] <SimonKLB> the application name, that is
[13:22] <SimonKLB> s/relation/interface
[13:38] <marcoceppi> SimonKLB: juju-info is that relation
[13:38] <marcoceppi> well, that's the interface
[13:38] <SimonKLB> oooh, i thought that was only intended for subordinate charms
[13:38] <marcoceppi> SimonKLB: oh, you want this for primary charms?
[13:39] <SimonKLB> marcoceppi: yes
[13:39] <marcoceppi> I've never tried, but it theoretically *should* work
[14:00] <SimonKLB> marcoceppi: doesnt look like it works out of the box - ERROR charm "testcharm" using a reserved relation name: "juju-info"
[14:01] <marcoceppi> SimonKLB: relation name, what's the metadata look like?
[14:01] <SimonKLB> marcoceppi: i guess this is the relevant part:
[14:01] <SimonKLB> subordinate: false
[14:01] <SimonKLB> requires:
[14:02] <SimonKLB>   juju-info:
[14:02] <SimonKLB>     interface: juju-info
[14:02] <marcoceppi> SimonKLB: don't call the relation juju-info
[14:02] <marcoceppi> call it anything else but that
[14:03] <SimonKLB> marcoceppi: doesnt seem to make a difference
[14:03] <petevg> cory_fu: PR for you: https://github.com/juju/python-libjuju/pull/28
[14:04] <SimonKLB> marcoceppi: nvm!
[14:04] <petevg> (I saw the code you merged, but I think that we still need to fix these two edge cases, too.)
[14:05] <SimonKLB> marcoceppi: shouldve tried that first :) thanks man!
[14:05] <marcoceppi> cheers
[14:12] <stub> Anyone know what happened with https://review.jujucharms.com/reviews/13 ?
[14:13] <stub> I think it was supposed to be promulgated, but https://jujucharms.com/nagios/ is the trusty only charm owned by Tom
[14:21] <marcoceppi> stub: there was a bit of a miscommunication then, I've reset things
[14:21] <marcoceppi> magicaltrout: there appears to already be a group of people taking up nagios, you may want to join them https://launchpad.net/~nagios-charmers
[14:21] <stub> More the merrier
[14:22] <marcoceppi> stub: can I request that more people be added to metadata.yaml maintainers?
[14:22] <stub> Sure. Not sure what it has atm.
[14:22] <marcoceppi> me and someone at nagios
[14:23] <marcoceppi> does nagios-charmers have a mailing list?
[14:23] <stub> That sounds like it needs fixing
[14:23] <marcoceppi> that might be the best for a "contact the maintainers"
[14:23] <stub> It could have, but I suspect half the people would filter it :-(
[14:23] <stub> Can we use the main juju list, or is that naughty?
[14:24] <marcoceppi> naughty :)
[14:24] <stub> Otherwise I can click the 'create a mailing list' button here in Launchpad
[14:24] <marcoceppi> eh
[14:24] <marcoceppi> it's a pretty low traffic list
[14:24] <marcoceppi> as the previous maintainer, I only ever recieved 1 email
[14:25] <stub> Launchpad has mailman builtin, but I suspect if I turned it on for something this low traffic emails would just get lost in mail filters.
[14:26] <stub> But at least it is a non main-juju-mailing-list contact point
[14:26] <marcoceppi> stub: as an additional maintainer
[14:26] <marcoceppi> I'm happy to stay on as a POC, but would hate to be the only POC
[14:27] <stub> oh, sure. I was thinking you would want out of there completely :)
[14:27] <marcoceppi> naw
[14:28] <marcoceppi> I am mildly interested in maintaining
[14:31] <deanman> Hi, any suggestion for an existing subordinate well maintained charm to study ?
[14:34] <marcoceppi> deanman: filebeat?
[14:38] <deanman> marcoceppi: on it
[14:40] <stub> https://api.jujucharms.com/charmstore/v5/nagios-14/archive/metadata.yaml
[14:40] <marcoceppi> +1
[14:48] <skay_> Hi, I ran `charm proof` on my new charm and I have warnings about missing hooks and amissing hook directory. when I generated the charm structure, it created a reactive directory. I've been putting hooks and reactive functions in my one file there.
[14:48] <petevg> cory_fu, bcsaller: I pushed another build of python-libjuju to matrix master's wheelhouse. Contains the fixes cory_fu and I pushed for edge cases.
[14:48] <skay_> based on running charm proof, should I split out the hooks in to a separate location?
[14:50] <petevg> skay_: if you're building a layered charm (which you probably are, if you're following the updated instructions), you need to do "charm build", and then run "charm proof" on the built charm.
[14:50] <marcoceppi> skay_: proof needs to be run after you do a charm build
[14:50] <skay_> ack, thanks
[14:50] <petevg> no worries :-)
[14:50] <skay_> much better :)
[14:53] <skay_> I have some hooks, like config-changed, that should switch status to 'maintenance' and then eventually switch to 'active'.
[14:54] <skay_> if an exception occurs between those, would the status be stuck in 'maintenance'?
[14:54] <skay_> and where can I look at how exceptions get handled by the framework so that I can determine if I should do some handling before allowing an exception to be raised
[14:55] <skay_> also, are there best practices for commenting on status and state transitions?
[14:55] <skay_> I didn't add comments on everything that transitions, but where something might not be clear I made a list of possible transitions
[14:55] <petevg> skay_: it should flip into an errored state if you have an unhandled Exception. Juju will then retry the hook, and stay in an errored state until the Exception goes away, or someone manually intervenes and fixes things.
[14:56] <skay_> thanks
[14:56] <petevg> skay_: Documenting transitions where they are not clear sounds like a best practice to me :-)
[14:56] <petevg> np
[14:56] <skay_> thanks I am just guessing here
[14:57] <skay_> okay, another question. I've been deploying my charm to try it out and it gets listed in an 'unknown' state, and I don't know why that happens
[14:57] <skay_> do you have advice on how to dig in to that?
[14:58] <skay_> listed by juju status
[14:59] <petevg> skay_: if I were troubleshooting, I'd read code and think through why a state wasn't getting set. You can add logging statements, or take a look at the documentation on the 'debug-hooks' command here:  https://jujucharms.com/docs/1.25/authors-hook-debug
[15:00] <petevg> And feel free to file issues or make contributions to juju docs (https://github.com/juju/docs) -- they could definitely be clearer about some of this stuff.
[15:00] <skay_> petevg: thanks. (I'm using juju2 so I'd go to a different url)
[15:00] <skay_> petevg: :)
[15:00] <skay_> petevg: I'm never sure when something is supposed to be obvious or not :)
[15:00] <petevg> skay_: yep. The correct url is https://jujucharms.com/docs/stable/authors-hook-debug  Sorry about that.
[15:01] <petevg> skay_: if it's not obvious to you, it's probably not obvious to someone else. Asking questions is always good. Filing issues when you get a good answer that isn't in the docs is even better :-)
[15:02] <petevg> skay_: in other words, thank you for the excellent questions :-)
[15:16] <rick_h> jcastro: ping
[15:18] <jcastro> yo
[15:19] <rick_h> jcastro: got a sec for prep?
[15:19] <jcastro> yeah, fire it up!
[15:20] <rick_h> jcastro: wanted to make sure the agenda is good, you mentioned some adding yesterday
[15:20] <mbruzek> rick_h: Will the link be here so we can join the show?
[15:20] <rick_h> mbruzek: definitely
[15:20] <mbruzek> looking forward to it, carry on with prep
[15:20] <rick_h> jcastro: can you use the one for the show just not hit record for prep?
[15:20] <jcastro> rick_h: I think marcoceppi wants to crash the party!
[15:20] <rick_h> jcastro: or a diff one ?
[15:20] <jcastro> right, working that now
[15:20] <rick_h> woot! crashing is fun
[15:21] <jcastro> https://hangouts.google.com/hangouts/_/ytl/mmAQjIgU5Fj-06oIFgojUAUgmlXJO-VnVCiW-omyT_g=?eid=103184405956510785630
[15:21] <jcastro> give it 30 seconds
[15:22] <jcastro> http://youtu.be/wo23ZXwa8ZU to listen in
[15:22] <marcoceppi> jcastro: "that's an error" when accessing page
[15:22] <marcoceppi> nvm
[15:22] <rick_h> loaded here
[15:43] <marcoceppi> https://lists.ubuntu.com/archives/juju-dev/2016-November/006169.html
[15:44] <jrwren> sounds like keystone charms are so good that its the easiest identity management on juju
[15:52] <mbruzek> Are there any questions for the Juju show live on you tube right now? http://youtu.be/wo23ZXwa8ZU
[15:52] <marcoceppi> http://summit.juju.solutions/
[16:11] <CoderEurope> Wich #channel should I be in for the Juju Show ?
[16:11] <zeestrat> CoderEurope: This one.
[16:12] <CoderEurope> zeestrat: Cheers - wheres jcastro ?
[16:12] <zeestrat> Not sure. Ping rick_h or mbruzek for questions
[16:13] <mbruzek> zeestrat: either
[16:13] <CoderEurope> rick_h, mbruzek I would like to chat with jcastro about a project that I am kicking around. Can I talk to him after the show ?
[16:14] <arosales> jcastro: rick_h is the hangout still live?
[16:14] <mbruzek> CoderEurope: Absolutely you can
[16:14] <rick_h> arosales: yes
[16:14] <arosales> mind if I drop in?
[16:14] <arosales> https://hangouts.google.com/hangouts/_/ytl/mmAQjIgU5Fj-06oIFgojUAUgmlXJO-VnVCiW-omyT_g=?eid=103184405956510785630 isn't working for me
[16:14] <arosales> 403
[16:14] <rick_h> arosales: :/ not sure
[16:14] <mbruzek> probably because we are live now
[16:15] <bdx> https://hangouts.google.com/hangouts/_/ytl/mmAQjIgU5Fj-06oIFgojUAUgmlXJO-VnVCiW-omyT_g=
[16:15] <jcastro> https://hangouts.google.com/call/ymfbnowfynfabphu36fwwyk46ee
[16:15] <jcastro> try this one
[16:15] <jcastro> you can both drop in if you'd like!
[16:15] <CoderEurope> me too ?
[16:15] <mbruzek> sure
[16:16] <jcastro> yeah!
[16:16] <marcoceppi> jump in, we've got like 15-20 mins to hang out
[16:26] <zeestrat> rick_h: Thanks for going through my questions. Much appreciated!
[16:26] <rick_h> zeestrat: np! thanks for the feedback/questions!
[16:36] <CoderEurope> @jcastro, Something went snap on my hangout.
[16:39] <CoderEurope> jcastro, thank-you should be downloaded in 5mins. Thanks again.
[16:41] <vmorris> watching the playback on the hangout -- this discussion about openstack endpoints being on private networks is super relevant to my interests
[16:42] <vmorris> but isn't this the point of having internalurl and externalurl attributes in the endpoint?
[16:46] <bdx> vmorris: yea, but natting wasn't taken into consideration
[16:47] <bdx> vmorris: I'm quite sure that functionality is meant to be facilitated by having actual interfaces with ip addresses on the separate networks
[16:50] <vmorris> bdx: ah i see now, ty
[17:02] <beisner> hi bdx, marcoceppi - re: barbican, be aware that the it is intended to be used with an hsm.  when used without it, you'll want to be aware of the warning @ http://docs.openstack.org/developer/barbican/setup/dev.html which we've also echoed in the charm release notes @ http://docs.openstack.org/developer/charm-guide/1610.html#barbican
[17:04] <wxl> zeestrat: thank you kindly. is 2.0 docuemnted outside of the man page?
[17:23] <zeestrat> wxl: All of the updated docs for 2.0 is up on https://jujucharms.com/docs/stable/ (see https://jujucharms.com/docs/stable/commands for commands for example)
[17:24] <zeestrat> Some charms might be a bit older and therefore refer to juju 1.x commands and concepts.
[17:38] <bdx> beisner: thanks for that
[17:41] <bdx> beisner: Note that this plugin DOES NOT WORK at present due to
[17:41] <bdx> bug#1611393.y
[17:42] <bdx> beisner: so its not really usable to that end
[17:43] <beisner> bdx, exactly.  the idea here is:  standalone barbican is a poc/test only scenario.  or, provide a hardware hsm and point barbican at it.  or eventually resume softhsm work when the stars align wrt versions.
[17:43] <bdx> I see
[17:47] <bdx> I don't want to believe it though
[17:47] <bdx> this spoils all my fun
[17:48] <bdx> beisner: jerk
[17:48] <bdx> jp :)
[17:49] <beisner> bdx, haha. just looking out for ya :)
[17:49] <bdx> much appreciated
[17:50] <beisner> bdx, i've not looked, but i would guess that for yakkety and onward, the necessary openssl library versions are in line with continuing the softhsm work.  but i don't think we've got that roadmapped atm.  an opportunity to collab/explore?
[17:52] <bdx> yeah ... yakkety has 1.0.2g-1ubuntu9
[17:54] <bdx> I would love to get this working ..... I have devs from other teams super interested in implementing what I've showed them in there organizations too .... not sure how apt they are to actually helping move it forward
[17:55] <bdx> beisner: is there a roadmap to get 1.0.2h in xenial at all?
[17:55] <bdx> their*^
[17:56] <beisner> bdx, i'm not sure but short of a major vulnerability, xenial's default stance will be on version stability generally speaking.
[17:57] <bdx> beisner: do you know who deals with, or would know more about the openssl packaging?
[17:58] <beisner> bdx, ubuntu security team, i believe.  have a look through https://launchpad.net/ubuntu/xenial/+source/openssl/+changelog
[17:59] <bdx> thx
[17:59] <bdx> mdeslaur: how's it going?
[18:00] <bdx> mdeslaur: would you mind chiming in here?
[18:02] <bdx> xnox, jmbl: ^^
[18:04] <bdx> beisner: possibly those guys aren't on #juju all the time, should I email the group of what looks like 4 or 5 maintainers concerning this you think, or openstack/juju lists?
[18:07] <beisner> bdx, it's worth getting familiarized with https://wiki.ubuntu.com/StableReleaseUpdates - those are the folks who will likely err on the side of version stability, for many good reasons of course.  that is not to say that it cannot happen.
[18:08] <beisner> o/ bdx - i've gotta check out.  cheers
[18:08] <bdx> beisner: oooh 1.0.2h isn't stable yet
[18:08] <bdx> beisner: ok, thanks
[18:18] <wxl> zeestrat: thank you!
[18:21] <xnox> bdx, beisner - i'm lost, what is the question?
[18:22] <xnox> bdx, beisner - we do not take openssl point releases, we cherrypick CVE fixes only. If there is a specific CVE you are after, you can check the security CVE tracker.
[18:22] <xnox> if you are after any other performance enchancement or fixes, it may need stand alone SRU.
[18:23] <xnox> that's my understanding.
[18:23] <beisner> xnox, ack, same understanding here.
[18:23] <beisner> thanks xnox
[18:28] <jacekn> hello. What's the process to get https://jujucharms.com/apache2/trusty/20 cham pushed to xenial series? It should work just fine form what I can see
[18:34] <bdx> xnox: thanks
[20:15] <cory_fu> bcsaller: If an additional matrix suite wants to override a rule in a test, should we match the rules up by task like we do tests by name?  Also, how do we handle removing args from a rule, or removing a rule entirely?  Or is it always just additive?
[20:15] <cory_fu> (Current implementation is match by name and task and always add or override)
[20:17] <cory_fu> I suppose you could remove an arg by setting it to None, but no way to remove an entire rule
[20:17] <cory_fu> bcsaller, petevg: What about "task" becoming a top-level rule key and "do" changing to "args"?
[20:17] <cory_fu> I think that might be clearer anyway
[20:18] <cory_fu> Hrm.  Still doesn't really help with deleting rules (or tests)
[20:18] <petevg> cory_fu: it feels like the right thing to do is just to write a new test.
[20:18] <cory_fu> petevg: What if you want all but one of the default tests?
[20:19] <petevg> cory_fu: you're kind of moving toward writing an inheritance system for tests. That's interesting, but might be out of scope.
[20:19] <petevg> I can see wanting to avoid copypasta, though ...
[20:19] <cory_fu> petevg: Well, we originally talked about it as more of a type of inheritance, but that's hard to do with just yaml
[20:19] <petevg> Yeah ... gets messy quickly.
[20:20] <cory_fu> petevg, bcsaller: Could support a special "delete: True" attribute, perhaps
[20:20] <cory_fu> tests: [{name: foo, delete: True}]
[20:20] <cory_fu> Or tests: [{name: foo, rules: {task: bar, delete: True}}]
[20:21] <bcsaller> cory_fu: sorry, on another call. I'd suggest a new version of an existing name overwrites it, not extends it (though there might be real use cases for that...)
[20:21] <cory_fu> bcsaller: Just at the rule level, or overwrite the entire test?
[20:22] <bcsaller> the entire test
[20:22] <cory_fu> Hrm.  That seems heavy handed.  I feel like something small like tweaking a timeout or period should be easier than that
[20:23] <bcsaller> then you need a syntax for handling deletes and so on like you said
[20:23] <cory_fu> Or even just adding an additional rule to an existing test
[20:25] <cory_fu> petevg: Thoughts on only being able to add new tests or entirely overwrite existing ones, rather than being able to tweak it by adding a rule or changing an arg?
[20:26] <cory_fu> bcsaller: Regardless of that, I feel like moving the task name up a level makes more sense to me.
[20:26] <petevg> cory_fu: My brain is mush right now, but I like the simplicity of just having to override an entire test.
[20:26] <petevg> It means duplicated yaml.
[20:27] <petevg> But less duplicated yaml than having to write a whole new .yaml
[20:27] <cory_fu> {do: deploy, args: {version: previous}}
[20:27] <cory_fu> petevg: Ok, I'm out voted, then I guess
[20:28] <petevg> cory_fu: sorry.
[20:28] <cory_fu> no problem.  Less code to maintain in matrix.  :)
[21:03] <cory_fu> bcsaller, petevg: https://github.com/juju-solutions/matrix/pull/26 updated for review
[21:56] <beisner> anyone have advice/workarounds for juju controller mem leak/usage issues? http://i.imgur.com/C1WpcK2.png  in just a couple of hrs with the lxd provider i've succeeded in OOMing and Calltracing the pretty beefy host.  juju 2.0.1
[21:59] <alexisb> beisner, move to 2.0.2
[22:00] <beisner> hi alexisb - wherefrom?
[22:00] <alexisb> it is in proposed atm
[22:01] <alexisb> beisner, there may be other work arounds, but 2.0.2 release has some good fixes in it around controller exhaustion issues
[22:01] <beisner> alexisb, ack.  will tear down, upgrade, redeploy and stuff.  many thanks.
[22:32] <cory_fu> petevg: Usage examples added
[22:32] <cory_fu> bcsaller: ^
[22:41] <petevg> cory_fu: yay docs!
[22:42] <skay_> for the 2nd time maybe I've had a crash report pop up from juju-deployer. has that happened to anyone else?
[22:43] <cory_fu> petevg: Did I mention that that PR has the newest libjuju with your fixes for the controller panics?  I thought those fixes were in master, but I was still getting them until I updated libjuju again
[22:43] <petevg> cory_fu: interesting. I thought that I had updated this morning. Maybe I forgot to pull python-libjuju master or something ...
[22:43] <petevg> cory_fu: are you sure that it's not just that you didn't rebuild your tox environment?
[22:44] <cory_fu> That's possible, but I thought I did
[22:44] <cory_fu> I can test it real quick
[22:45] <cory_fu> petevg: Yeah, you're right.  It seems to be working on master now
[22:46] <petevg> cory_fu: the semantics of matrix in your PR are a little confusing. If I have a bundle that sits at, say ~/Code/bigtop.hadoop/bigtop-deploy/juju/hadoop-processing/, and it doesn't have a matrix.yaml, but I want to run the default matrix test suite, how do I do so?
[22:47] <petevg> skay_: I haven't had deployer pull up a crash report, if by "crash report", you mean Ubuntu's crash reporter. I have had it just plain crash, but not recently.
[22:48] <cory_fu> petevg: matrix  ~/Code/bigtop.hadoop/bigtop-deploy/juju/hadoop-processing/
[22:48] <skay_> petevg: yeah, it's trigger Ubuntu's crash reporter. surprised me
[22:48] <skay_> I'm running a mojo manifest
[22:49] <petevg> cory_fu: that's what I thought the docs were telling me, but that doesn't work.
[22:49] <cory_fu> petevg: tests/matrix.yaml is included if present, but can be excluded with -B.  The default suite is always included unless excluded with -D
[22:50] <petevg> cory_fu: My matrix log: http://paste.ubuntu.com/23560175/
[22:50] <petevg> (It looks like its trying to interpret the bundle as a matrix test.)
[22:50] <cory_fu> petevg: Sorry, that should have been: matrix -p  ~/Code/bigtop.hadoop/bigtop-deploy/juju/hadoop-processing/
[22:51] <cory_fu> CLI args are additional suites.  -p <path> is the path to the bundle.
[22:51] <petevg> cory_fu: Aha. That's it. It tried running -Dp from the example, but that only works if there's a matrix.yaml file, I think.
[22:52] <cory_fu> petevg: Added another usage example for that
[22:53] <petevg> cory_fu: awesome. Was just about to ask you to do that :-)
[22:53] <cory_fu> petevg: Yeah, if you use -D and there's no tests/matrix.yaml, you'll have no suites.  Should probably catch that and report more nicely
[22:54] <petevg> cory_fu: merged. This is awesome stuff -- saves me a lot of find-replacing when I test hadoop-processing :-)
[22:57] <cory_fu> bcsaller: Where would I look to colorize log messages in matrix?
[22:58] <bcsaller> cory_fu: easier to explain in a hangout
[22:59] <cory_fu> bcsaller: Ok, I'm in matrix daily
[23:01] <alexisb> thumper, axw ping
[23:04] <skay_> juju-deployer stacktrace https://www.irccloud.com/pastebin/O28WeBHn/
[23:05] <skay_> not sure why the above happened
[23:15] <cory_fu> petevg, bcsaller: Quick PR and I'm EOD.  Have a good one
[23:15] <cory_fu> petevg, bcsaller: Helps if I include the link; https://github.com/juju-solutions/matrix/pull/30
[23:29] <cory_fu> bcsaller: Removed the  unused block and merged
[23:29] <bcsaller> cory_fu: thanks
[23:35] <tvansteenburgh> skay_: i'd check the juju logs on that one. looks like something went wrong server-side