[00:55] <gary_poster> hatch, fwiw scrollview-base-ie is definitely in all-yui.js.  Could this be a yui regression of some sort?
[00:57]  * gary_poster tries yui 3.9.0
[00:59]  * gary_poster still gets same or similar errors
[01:01] <gary_poster> pretty much the same
[01:03] <gary_poster> so anyways hatch, if you look for scrollview-base-ie in build-shared/juju-ui/assets/all-yui.js, you'll find it
[01:03] <gary_poster> dunno beyond that :-/
[01:07]  * gary_poster goes away
[02:54] <hatch> gary_poster: darn you're right - well without those tests they all pass in IE10 so once jc removes them tomorrow we can land this branch :D
[02:59] <bcsaller> gary_poster: thanks for the review
[02:59] <gary_poster> welcome bcsaller :-)
[02:59]  * gary_poster runs away again
[08:13] <rogpeppe> frankban: hiya
[08:14] <frankban> morning rogpeppe
[08:14] <rogpeppe> frankban: i've got some branches up for review which give us unit and machine status
[08:15] <rogpeppe> frankban: if you wanted to have a look, that would be great
[08:15] <frankban> rogpeppe: yay!
[08:15] <rogpeppe> frankban: these are the branches: https://codereview.appspot.com/8458044/ https://codereview.appspot.com/8487044/ https://codereview.appspot.com/8533044/ https://codereview.appspot.com/8534043/
[08:18] <frankban> rogpeppe: will do asap.
[08:19] <rogpeppe> frankban: ta!
[10:08] <frankban> rogpeppe: could you please take a look at https://codereview.appspot.com/8566043 ? This is the branch fixing the DerviceDeploy panic.
[10:08] <rogpeppe> frankban: will do
[10:08] <frankban> rogpeppe: ty
[10:35] <rogpeppe> frankban: unit and machine statuses have landed
[10:35] <frankban> rogpeppe: hah, I was taking a look too, cool!
[10:36] <rogpeppe> frankban: if you have any comments, please let me know, and i'll address them in the next branch (which adds service constraints)
[11:00] <frankban> rogpeppe: the delta stream including statuses works great. Am I right assuming StatusInfo is only relevant when a unit or a machine is in an "error" status?
[11:00] <rogpeppe> frankban: wonderful!
[11:00] <rogpeppe> frankban: yeah, i'm pretty sure that's true
[11:01] <rogpeppe> frankban: might be worth double checking with fwereade or dimitern on #juju-dev
[11:01] <frankban> rogpeppe: I'll do, thanks
[11:07] <rogpeppe> frankban: in your bug-1166224-service-deploy-panic branch, have you run all tests ok?
[11:08] <frankban> rogpeppe: yes
[11:09] <fwereade> frankban, rogpeppe: I would say that all the statuses are "important", but the error status is the only one to which a user might want to respond directly
[11:10] <rogpeppe> fwereade: it was StatusInfo i wasn't entirely sure about
[11:10] <rogpeppe> fwereade: not importance
[11:10] <fwereade> rogpeppe, ah sorry -- count me officially undecided there
[11:11] <fwereade> rogpeppe, I think there's opportunity for more richness in the future but as it is it's not used much (at all? not sure)
[11:11] <rogpeppe> fwereade: ok
[11:11] <rogpeppe> frankban: seems like i wasn't the only one to be unsure :-)
[11:12] <frankban> fwereade, rogpeppe: that's ok, I think we can show StatusInfo in the GUI only if it's not an empty string.
[11:12] <fwereade> frankban, sgtm, matches the cli status
[11:12] <rogpeppe> frankban: that seems like a nice approach
[11:14] <rogpeppe> frankban: interesting that all tests pass. i guess we never call CharmStore.Get in any non-charm-package tests
[11:14] <rogpeppe> frankban: i'm pretty sure that if you use that branch for real, you'll get a panic
[11:15] <frankban> rogpeppe: i tried it for real, just bootstrap and deploy charms via the API, are there any real operations not covered by tests?
[11:15] <rogpeppe> frankban: it'll work if you do everything via the API
[11:16] <rogpeppe> frankban: but a command line deploy will panic
[11:17] <frankban> rogpeppe: trying now
[11:23] <frankban> rogpeppe: you are right, so it seems that MachineAgent.Run is not called when the charm is deployed via the command line
[11:24] <rogpeppe> frankban: MachineAgent.Run is only called in the machine agent
[11:24] <rogpeppe> frankban: i'm just posted a review
[11:24] <rogpeppe> i've
[11:24] <rogpeppe> frankban: that suggests the fix that i mentioned yesterday
[11:27] <frankban> rogpeppe: thanks. so the charm dir can be set by ma.Run OR by InitJujuHome, depending on the code path we follow (i.e. a cmd line call or an API call)
[11:27] <rogpeppe> frankban: that's right
[11:28] <frankban> and InitJujuHome goes in conn.go (package juju)
[11:28] <frankban> rogpeppe: ^^
[11:28] <rogpeppe> frankban: sounds good
[11:37] <rogpeppe> frankban: do you think that a set of constraints would be better json'd as a string or an object?
[11:39] <frankban> rogpeppe: if it's a set than an object would work well. anyway, I am confused about them as a string, an example?
[11:40] <rogpeppe> frankban: there's a canonical representation of constraints as a string, e.g. "mem=1024M cores=2"
[11:44] <bac> teknico, frankban: fancy a review? https://codereview.appspot.com/8532043
[11:45] <teknico> bac, actually right now I'm fancying something to eat :-)
[11:45] <bac> teknico: a perfect after-lunch activity!
[11:46] <teknico> bac, indeed!
[11:49] <frankban> rogpeppe: oic, as they are passed on the command line. We can handle them both ways. FWIW, the object representation seems more appropriate to me, if the implementation is not complex.
[12:01]  * frankban lunches
[12:14] <benji> the board is still super flaky
[12:18] <gary_poster> teknico, frankban sorry we didn't have any one to finish up your bug yesterday.  thank you for bringing it to completion
[12:28] <gary_poster> rogpeppe, awesome that status is landed, thank you!
[12:28] <rogpeppe> gary_poster: np
[12:28] <rogpeppe> gary_poster: i'm now just doing the tests for service constraints
[12:28] <gary_poster> great!
[12:28] <rogpeppe> gary_poster: any particular priority on other attributes?
[12:29] <gary_poster> just reviewing...
[12:33] <gary_poster> rogpeppe, config and constraints in the deltas are nice to have for 13.04 from our perspective going forward.  we want to focus on bug fixes that require juju core changes, so the current work on bug 1166224, the current work for bug 1164593, a fix for bug 1166222, a fix for bug 1161848, and repeated testing to see what else might be broken are where we need to focus on our side
[12:33] <_mup_> Bug #1166224: Panic when calling ServiceDeploy via the juju-core API <juju-core:Triaged> <juju-gui:In Progress> < https://launchpad.net/bugs/1166224 >
[12:33] <_mup_> Bug #1164593: GUI hangs on the service detail view when connected to juju-core <juju-core:New for bac> <juju-gui:In Progress by bac> < https://launchpad.net/bugs/1164593 >
[12:33] <_mup_> Bug #1166222: Error when calling CharmInfo using the juju-core API <juju-core:New> <juju-gui:Triaged> < https://launchpad.net/bugs/1166222 >
[12:33] <_mup_> Bug #1161848: Malformed charm metadata error when a charm is deployed using the API <juju-core:New> <juju-gui:Triaged> < https://launchpad.net/bugs/1161848 >
[12:34] <rogpeppe> gary_poster: what about service config settings changes?
[12:34] <gary_poster> rogpeppe, we want them, and PyJuju provides them, but if we don't have them for 13.04 we can do an acceptable workaround on the JS side
[12:35] <rogpeppe> gary_poster: ok, cool
[12:36] <rogpeppe> gary_poster: frankban has the ServiceDeploy panic in hand
[12:36] <gary_poster> right, those first two are in review
[12:36] <gary_poster> on the juju-core side
[12:37] <gary_poster> actually rogpeppe, bac might want your review for that second one: https://codereview.appspot.com/8532043/
[12:37] <rogpeppe> frankban: have you got a reliable way of reproducing #1166222 ?
[12:37] <_mup_> Bug #1166222: Error when calling CharmInfo using the juju-core API <juju-core:New> <juju-gui:Triaged> < https://launchpad.net/bugs/1166222 >
[12:38] <rogpeppe> gary_poster: on it
[12:38] <gary_poster> than kyou
[12:40] <gary_poster> ugh, canonistack is killing our CI
[12:47] <gary_poster> jcsackett, hey.  I heard from hatch that you'll be removing the requirement to use the scrollview (and thus the scrollview-base-ie that is causing us problems with a "fix up tests" branch).  Is that already in review?  I'm basically wondering when we might be able to land our branch without having to figure out what why that file isn't being honored in production
[12:47] <rick_h_> gary_poster: it's the card for today. It'll probably be closer to EOD to get in review/landed
[12:48] <gary_poster> ok thanks rick_h_
[12:48] <rick_h_> gary_poster: there's a few cards from yesterday still in reveiw that I imagine will get finished/landed but after that should be a bunch of easy 'rm ...' commands
[12:48] <gary_poster> rick_h_, :-) cool
[12:51] <rogpeppe> bac: ping
[12:54] <bac> hi rogpeppe
[12:54] <rogpeppe> bac: i'm just wondering if ServiceInfo.Charm should be ServiceInfo.CharmURL
[12:55] <rogpeppe> bac: that way it can be used to cross-reference to all the charm metadata
[12:55] <bac> rogpeppe: are you referring to bug 1166222?  if so, that's frankban's branch
[12:55] <_mup_> Bug #1166222: Error when calling CharmInfo using the juju-core API <juju-core:New> <juju-gui:Triaged> < https://launchpad.net/bugs/1166222 >
[12:55] <rogpeppe> bac: i don't *think* so. i just noticed the use of Charm when reviewing your branch.
[12:56] <rogpeppe> bac: i've been just called to lunch. back in a bit!
[12:56] <bac> rogpeppe: have a good lunch.  i'll have a look
[12:59] <frankban> rogpeppe: http://pastebin.ubuntu.com/5692278/ reproduces the CharmInfo bug.
[13:06] <frankban> gary_poster: IIRC I cannot reproduce bug 1161848 anymore. I'll try it again after fixing the current deploy branch, and, if that's the case, I'll mark the issue as fixed
[13:06] <_mup_> Bug #1161848: Malformed charm metadata error when a charm is deployed using the API <juju-core:New> <juju-gui:Triaged> < https://launchpad.net/bugs/1161848 >
[13:06] <gary_poster> frankban, fantastic, thanks
[13:18] <teknico> bac, branch approved
[13:18] <bac> rogpeppe: i don't understand your question.  ServiceInfo has CharmURL
[13:18] <bac> teknico: thanks
[13:19] <rogpeppe> bac: sorry, wrong type. i'm talking about ServiceGetResults
[13:19] <rogpeppe> bac: in fact, eventually i think ServiceGet should just return a ServiceInfo
[13:20] <bac> rogpeppe: the names were originally chosen for compatability with the py api.  but we can change them
[13:21] <bac> rogpeppe: s/compatability/consistency
[13:21] <rogpeppe> bac: it's not just the name - it's the information that's sent across
[13:21] <rogpeppe> bac: the url is what we use to cross-reference charms elsewhere
[13:21] <rogpeppe> bac: the charm meta name can be found from that, i think
[13:22] <rogpeppe> gary_poster: here's the branch that adds constraints to the ServiceInfo: https://codereview.appspot.com/8568044
[13:22]  * gary_poster looks
[13:27] <bac> rogpeppe: with your addition of constraints it does make sense to change ServiceGetResults
[13:27] <rogpeppe> bac: not quite yet, i think
[13:27] <rogpeppe> bac: no config available yet
[13:28] <bac> rogpeppe: i didn't mean solely but as part of the return
[13:29] <rogpeppe> bac: perhaps.
[13:29] <bac> rogpeppe: i mean ServiceInfo as a subset of ServiceGetResults
[13:29] <rogpeppe> bac: yeah
[13:29] <rogpeppe> bac: i'm not sure
[13:29] <rogpeppe> bac: it depends how we want to deliver changes to service config
[13:30] <rogpeppe> bac: if we want to put them in the ServiceInfo, then i think it makes sense to have ServiceGetResults be exactly the same thing as ServiceInfo
[13:30] <rogpeppe> bac: if not, then perhaps not.
[13:31] <rogpeppe> bac: is there any other stuff which might go into ServiceGetResults that we wouldn't want in the ServiceInfo ?
[13:32] <bac> rogpeppe: for the GUI the things in my branch are what we currently need and i don't anticipate that needing to be extended
[13:32] <gary_poster> rogpeppe, I really like the recent changes to the megawatcher.  I find it much easier to read the setup now for changes like this.  The table tests look like a good set as well.
[13:32] <gary_poster> Count that as an unofficial LGTM ;-)
[13:32] <rogpeppe> gary_poster: cool, glad to hear it
[13:32] <rogpeppe> pwd
[13:33] <gary_poster> ~/dev/juju-gui
[13:33] <rogpeppe> gary_poster: 474 lines in one of those tables :-)
[13:34] <gary_poster> rogpeppe, yeah, even one of the tests is a bit overwhelming but I like the clear division between setup and test and so on
[13:35] <gary_poster> "overwhelming" is not fair, but I had to stare longer at that code than anywhere else :-)
[13:35] <rogpeppe> gary_poster: which test was that?
[13:35] <gary_poster> status is changed if the service exists in the store
[13:36] <gary_poster> I think the rietveld wordwrap didn't help either
[13:37] <gary_poster> clearer without, like in https://codereview.appspot.com/8568044/patch/2001/3004
[13:37] <rogpeppe> gary_poster: yeah. there is actually a lot of repetition between the different sets of entries. i haven't worked out a way to factor it out decently yet though.
[13:37] <benji> bac: heh; something changed the option double-dashes in your blog post into em-dashes
[13:37] <gary_poster> yeah, and you want to be able to have someone read a single test
[13:37] <rogpeppe> gary_poster: maybe i should put those MustParse expressions on a separate line
[13:38] <gary_poster> would be nicer in 80 chars/rietveld certainly :-)
[13:39] <rogpeppe> gary_poster: i think i could probably unindent the whole table by one tab, which would help
[13:39] <gary_poster> that would be cool
[13:39] <gary_poster> and honestly this is just a rietveld thing IMO
[13:40] <bac> benji: it is a little better now
[13:40] <gary_poster> so low priority in the small (though perhaps an argument for a line length goal for the project in the large?)
[13:41] <rogpeppe> gary_poster: the current party line is "if someone has a problem with a line, make it smaller" :-)
[13:41] <benji> bac: by better do you mean that now there are two em-dashes?  :)  those still aren't hyphens
[13:41] <bac> ndashes
[13:41] <gary_poster> rogpeppe, lol, cool
[13:41]  * gary_poster returns to writing fun rt email about canonistack problems
[13:41] <benji> true, they aren't quite long enough to be em dashes are they
[13:42] <gary_poster> benji and bac, you are silly
[13:42] <gary_poster> and thanks for blog post bac
[13:42] <bac> gary_poster: you just wait until i get this sorted out.  its going to rock then.
[13:42] <gary_poster> :-)
[13:43] <rogpeppe> gary_poster: i can't lose the indent without losing those handy section markers
[13:43] <gary_poster> rogpeppe, +1 on handy section markers
[13:43] <rogpeppe> gary_poster: unless i use this style: }, /* Annotation changes */ {
[13:43] <bac> benji: what about now?
[13:43] <rogpeppe> gary_poster: which i'm not keen on
[13:44] <gary_poster> rogpeppe, agree
[13:44] <benji> ooh, look at those nice hyphens
[13:45] <bac> benji: i wish i had need for a"mongolian todo soft hyphen"
[13:45] <bac> ᠆
[13:46] <benji> is that the character mongolian people use when listing out their todos in a text editor?
[13:46]  * rogpeppe loves the silky feel of those soft hyphens
[13:46] <gary_poster> lol
[13:47] <benji> lol
[13:48] <rogpeppe> frankban: i can't reproduce your bug
[13:49] <rogpeppe> frankban: one thing: i had to change the charm URL to cs:precise/wordpress-11
[13:49] <rogpeppe> frankban: presumably someone has updated the latest revision of the wordpress charm
[13:49] <rogpeppe> frankban: but given that change, the script you pasted above worked perfectly for me
[13:50] <frankban> rogpeppe: are you using a precise bootstrap node? could it be related to --fake-series?
[13:50] <rogpeppe> frankban: it's possible. did you bootstrap with --fake-series precise ?
[13:50] <frankban> rogpeppe: yes, from a quantal juju-core trunk
[13:51] <rogpeppe> frankban: hmm. presumably you used the wordpress URL that was shown in the status?
[13:52] <frankban> rogpeppe: at first I just used the URL generated by the GUI
[13:53] <frankban> rogpeppe: I'll investigate further, in order to give you more details
[13:54] <rogpeppe> frankban: thanks. a full transcript of it going wrong, including status output, might be helpful
[13:55] <frankban> rogpeppe: sure
[13:55] <hatch> good morning
[13:55] <rogpeppe> so... if i want to try out the GUI, what do i need to do?
[13:55] <teknico> rogpeppe, how do we test code that calls os.Exit() ? starting subprocesses in tests is not common :-)
[13:55] <rogpeppe> teknico: in general, you don't
[13:56] <rogpeppe> teknico: although you can
[13:56] <rogpeppe> teknico: why is your code calling os.Exit?
[13:56] <frankban> rogpeppe: this could help: http://jujugui.wordpress.com/2013/04/04/debugging-juju-gui-juju-core-connection/
[13:57] <rogpeppe> frankban: cool, thanks!
[13:58] <teknico> rogpeppe, checkJujuHome calls it
[13:58] <rogpeppe> teknico: ah, it should not!
[13:58] <teknico> teknico, I guess we can neglect that code path :-)
[13:58] <teknico> or maybe not :-)
[13:59] <rogpeppe> teknico: it should be different now that it's a library function
[13:59] <rogpeppe> teknico: one mo, i'll take a look
[13:59] <teknico> rogpeppe, thanks
[14:00] <rogpeppe> teknico: it should probably just return an error
[14:01] <frankban> rogpeppe: ok, so, we put os.Exit in Main(args []string)?
[14:01] <rogpeppe> frankban: yup
[14:01] <frankban> rogpeppe: ack
[14:02] <rogpeppe> frankban: i hadn't seen the juju-gui blog before. nice!
[14:03] <frankban> :-)
[14:04] <rick_h_> hatch: jcsackett https://codereview.appspot.com/8491045/ review plead. hatch let me know if you can think of a better way to track those events for cleanup
[14:06] <benji> bac: I'm reviewing https://codereview.appspot.com/8532043
[14:07] <bac> benji: thanks.  i think rogpeppe is looking at it too.  more==merrier
[14:07] <teknico> so, if I set a title in a post, then it's a regular blog post, while if I set no title, it's microblogging? ;-)
[14:07] <Makyo> assert.deepEqual(more, merrier)
[14:07] <hatch> rick_h_ on it
[14:07] <benji> bac: oh, I won't bother then; there were no tags, that's why I called it out so I wouldn't duplicate work
[14:07] <rick_h_> hatch: thanks!
[14:08] <Makyo> teknico, There are different types of entries, too, but I think that's the long and short of it :)
[14:08] <benji> I'll add a Friday-talk-card so we can have a quick discussion about how we want to handle non-gui-team-project-review-claiming
[14:09] <rogpeppe> bac: reviewed
[14:10] <bac> rogpeppe: thanks
[14:11] <benji> Makyo: what was the outome of the yuidoc comment style cage match?
[14:11] <Makyo> benji, No asterisks, indented two spaces.
[14:12] <gary_poster> benji, Makyo sent a great email to list with summary
[14:12] <benji> cool
[14:12] <benji> :(  my email volume has apparently reached the point where there is so little of use to me that I don't recognize the things that are of use any more
[14:13]  * benji finds good email and enjoys reading it.
[14:22] <hatch> rick_h_ done LGTM- lemme know if you disagree with any of my comments
[14:22] <rick_h_> hatch: thanks
[14:23]  * hatch tries to remember what he was doing lastnight
[14:27] <gary_poster> hey hatch, just as a representative check, did you get the rt email I just sent out a minute or two ago with title "More reliable canonistack usage"?
[14:28] <gary_poster> I have not yet received an rt reply, and had some trouble sending
[14:28] <hatch> negative
[14:28] <hatch> there it is
[14:28] <gary_poster> oh cool thx
[14:29] <hatch> good email
[14:30] <gary_poster> cool thx
[14:36] <hatch> I think my 'alt' key is going :/ I probably go through one of these keyboards a year
[14:36] <hatch> it might be time to upgrade
[14:36] <rick_h_> hatch: time to get a real keyboard. mechanical switches ftw
[14:37] <hatch> http://www.microsoft.com/hardware/en-us/p/natural-ergonomic-keyboard-4000 is what I have
[14:37] <hatch> I really like the layout and whatnot
[14:38] <hatch> a couple of my dev friends swear by these http://www.kinesis-ergo.com/advantage.htm
[14:38] <hatch> but daymn $300
[14:39] <Makyo> Yeah, I use these http://www.goldtouch.com/p-1-goldtouch-v2-adjustable-comfort-keyboard-pc-only-includes-usb-and-ps2-connector.aspx Which are a bit much, but still, my wrists and fingers thank me.
[14:39] <hatch> yeah I used to have wrist problems until I switched to this keyboard
[14:39] <Makyo> Old boss used one of the Advantage keyboards.  Very, very loud :)
[14:40] <hatch> loud typing is more h4x0r though right?
[14:40] <Makyo> If you work alone :oP
[14:40] <rick_h_> hatch: ugh, I got one of those. mushiest thing ever. :(
[14:40] <Makyo> Sitting outside my boss's office, it was a little annoying.
[14:40] <rick_h_> I've got some unicomp that are really loud. buckling spring. I'm using a filco cherry blue right now which is kind of loud
[14:41] <rick_h_> but my friend got a leopold with cherry blacks that's pretty quiet
[14:42] <hatch> I'd be worried if I went to something like the kinesis that I woudln't be able to type on a laptop anymore heh
[14:42] <rick_h_> yea, I've got one of those.
[14:43] <rick_h_> the big thing there is that some of the keys like {} and such are hard to hit with the pinky
[14:43] <frankban> rogpeppe: I see a test failure in trunk: http://pastebin.ubuntu.com/5692484/
[14:43] <hatch> ahh
[14:44] <rogpeppe> frankban: hmm, you're right, i wonder when that happened
[14:46] <rogpeppe> frankban: 1129
[14:46] <rogpeppe> frankban: by someone called "Данило Шеган"
[14:47] <frankban> rogpeppe: danilos
[14:48] <rogpeppe> bac: i suspect you didn't run all tests after merging and before submitting your last branch :-)
[14:48] <teknico> frankban, you can read that? I don't even know what language it is :-)
[14:48] <bac> rogpeppe: but i did
[14:48] <rogpeppe> bac: hmm, odd
[14:48] <bac> rogpeppe: what's failing
[14:49] <bac> oic
[14:49] <rogpeppe> bac: maybe you submitted at exactly the same time
[14:49] <bac> let me pull the newest and try again
[14:50]  * rogpeppe wishes bzr showed timestamps in a consistent way
[14:50] <rogpeppe> teknico: looks like russian to me
[14:50] <bac> rogpeppe: yep, i just got a new constraints_test.
[14:51] <teknico> shouldn't bazaar refuse landing a branch if that branch did not include the latest trunk revno?
[14:52] <hatch> Makyo bug 1166827 when I was working with the N7 the zoom worked with the slider until I attempted to pinch on the enironment then nothing worked
[14:52] <_mup_> Bug #1166827: Mobile: zoom does not work <juju-gui:Triaged by makyo> < https://launchpad.net/bugs/1166827 >
[14:52] <hatch> just FYI
[14:53] <Makyo> hatch, yeah, I'm noticing that pan is fragile like that, too - any bumps along the way, and it stops working.  That'll be part of the investigation, though, since it's the same function. Also, a recent branch removes the slider.
[14:53] <hatch> ohh ok
[14:56] <Makyo> hatch, mind QAing/reviewing https://codereview.appspot.com/8362048/ at some point?  I want to make sure I didn't get it working on Ubuntu only to break it on Android.
[14:57] <hatch> sure - can it wait till this afternoon? I've been trying ot get this relations code landed :)
[14:58] <gary_poster> you could try bother rick too Makyo, because he has an android <shrug>
[14:58] <Makyo> gary_poster, Ah! Didn't know.  rick_h_ ^^^
[14:58] <Makyo> hatch, no worries.
[14:58] <rick_h_> Makyo: yea, I've got an N10 I can test it out on.
[14:58] <rick_h_> Makyo: will look in a few min if you need.
[14:59] <Makyo> rick_h_, Whenever's convenient.  Thanks.
[14:59] <bac> rogpeppe: so this constraints_test failure doesn't have anything to do with my branch.  do you know what's going on
[15:00] <rogpeppe> bac: yeah, i've just found out
[15:00] <bac> and?
[15:00] <rogpeppe> bac: you need to update your version of goyaml
[15:00] <rogpeppe> bac: i went into the goyaml directory and did: bzr pull lp:goyaml --remember
[15:21] <gary_poster> Makyo, I'm going to have to give you a LGTM without QA: phablet keyboard not working today :-/
[15:21] <Makyo> gary_poster, Alright, know how that goes.  Hopefully it's up for ODS
[15:21] <gary_poster> yeah
[15:22] <gary_poster> Makyo, was thinking once we find release that works over next two days we ought to both upload it and then not touch it
[15:22] <hatch> you know what's awesome? When you write code....then go write a test and it passes first try with the correct output :D
[15:23] <gary_poster> actually, Makyo if we discover a revision that works we can phablet-flash -r REVISION
[15:23] <gary_poster> do you know the revision of what you have by chance Makyo
[15:23] <Makyo> gary_poster, 59 is working well for me, with the only hindrance being that breakpoints in the inspector cause the browser to crash.
[15:23] <gary_poster> ok will try
[15:23] <Makyo> But that's a development thing.
[15:23] <rogpeppe> gary_poster: so... i just tried the gui, and i can't log in. is the admin-secret stuff working currently?
[15:24] <gary_poster> frankban, ^^^
[15:24] <rogpeppe> frankban: and i now realise that i'm surprised that your script can log in to the API even with a password of "passwd".
[15:25] <rogpeppe> frankban: this seems... not good. and it must be my fault!
[15:25] <frankban> rogpeppe: var AuthenticationEnabled = false in apiserver.go
[15:25] <rogpeppe> frankban: ha!
[15:26] <frankban> rogpeppe: you should be able to login to the GUI using user-admin and an arbitrary password
[15:26] <rogpeppe> frankban: it fails
[15:26] <frankban> rogpeppe: looking
[15:26] <rogpeppe> frankban: i see the web site
[15:27] <rogpeppe> frankban: see https://ec2-54-234-173-151.compute-1.amazonaws.com/
[15:27] <rogpeppe> frankban: but it won't let me log in
[15:27] <rogpeppe> frankban: nice login screen, BTW!
[15:27] <frankban> rogpeppe: have you deployed the GUI from the latest sources? (juju-gui-source=lp:juju-gui)
[15:28] <rogpeppe> frankban: i'll have a look
[15:28] <gary_poster> that's not in your blog post so I bet not
[15:28] <rogpeppe> frankban: i'm just using the latest version from the charm store
[15:28] <rogpeppe> frankban: rev 40
[15:29] <frankban> rogpeppe: I mean, "juju set juju-gui juju-gui-source=lp:juju-gui"
[15:30] <gary_poster> rogpeppe did you deploy juju-gui or did you do what frankban's blogpost had ($GOPATH/bin/juju deploy cs:~juju-gui/precise/juju-gui)
[15:30] <gary_poster> our charm is supposed to replace the ~charmers charm once jujcharms.com is flushed, nbut has not been flushed yet.  will check with m_3
[15:30] <gary_poster> hi m_3 :-)
[15:30] <gary_poster> forgot you were over here
[15:31] <rogpeppe> gary_poster: the latter
[15:31] <gary_poster> ok cool
[15:31] <gary_poster> then all you need is what frankban said
[15:31] <rogpeppe> gary_poster: i just did the juju set, but i still get the same results.
[15:32] <rogpeppe> gary_poster: do i have to re-deploy the charm?
[15:32] <gary_poster> rogpeppe, it will take a while to build
[15:32] <gary_poster> follow logs
[15:32] <gary_poster> or check back in 10 min :-)
[15:32] <rogpeppe> gary_poster: it takes that long?
[15:32] <frankban> rogpeppe: you might also want to refresh the browser very hard in 10 minutes :-)
[15:32] <gary_poster> lol, yeah
[15:33] <rogpeppe> gary_poster: i thought it was javascript!
[15:33] <gary_poster> rogpeppe, :-) you are building the release, which involves downloading lots of dependencies
[15:33] <rogpeppe> gary_poster: ah, it's downloading
[15:34]  * rogpeppe wants a --all argument to debug-log
[15:34] <gary_poster> +1
[15:34] <rick_h_> Makyo: so I can't tap on a charm in the environment any more to get up the optino to pick details/etc
[15:35] <Makyo> :(
[15:35] <Makyo> Can you drag a service with two fingers?
[15:35] <rick_h_> Makyo: yes, I can drag them around but nothing else it seems.
[15:35] <rick_h_> tapping on zoom no good, panning no good
[15:35] <hatch> I don't think I'll ever understand this linter and it's indenting rules
[15:36] <Makyo> rick_h_, zoom and pan are a separate bug, yeah, this was just for the service menus.
[15:36] <rick_h_> Makyo: ok, so yea I can two finger drag but no click
[15:36] <Makyo> rick_h_, Alright.  Hmm.
[15:36] <rogpeppe> gary_poster: https://bugs.launchpad.net/juju-core/+bug/1166863
[15:36] <_mup_> Bug #1166863: debug-log should make it possible to see previous messages <juju-core:New> < https://launchpad.net/bugs/1166863 >
[15:37] <Makyo> Really wish it worked on my phone.
[15:37] <rick_h_> Makyo: anything else I should test/qa then?
[15:37] <Makyo> rick_h_, I don't think so.  Was just the clicking and dragging.
[15:37]  * gary_poster tries to qa Makyo's branch again
[15:37] <rick_h_> ok, want me to reply in the CR or you cool here
[15:38] <Makyo> rick_h_, Go ahead and reply just for completeness' sake.
[15:38] <rick_h_> Makyo: rgr
[15:40] <rick_h_> Makyo: what do you think of working to setup a Y.log console if something is set in the url or something? and dumping out some event/trace useful for debugging when we qa something?
[15:40] <rick_h_> hatch: gary_poster ^
[15:40] <gary_poster> There was something bad about Y.log
[15:40]  * gary_poster hopes someone else remembers
[15:40] <Makyo> Logging objects and logging multiple arguments.
[15:40] <hatch> it doesn't tell you where its being logged from
[15:41] <hatch> you can log objects and multiple args just fine
[15:41] <hatch> but I think rick is talkign about YUI debug messages
[15:41] <frankban> rogpeppe: fwiw, I have a juju-gui instance here: https://ec2-23-22-239-162.compute-1.amazonaws.com/
[15:41] <rick_h_> yea, I want to get a console I can see in the browser to help copy/trace events and such
[15:41] <Makyo> Previously you had to pass an array, it wouldn't just console.log(arguments); new perhaps?
[15:42] <rick_h_> Makyo: in looking at your branch I wonder if the double event check stuff is what's breaking it now
[15:42] <rogpeppe> frankban: cool
[15:42] <hatch> hmm odd i've never ran into that issue Makyo
[15:42] <rick_h_> Makyo: but to verify that I'd want to console.log each event and see if it logged
[15:43] <Makyo> rick_h_, Yeah, I think so, which has me miffed that the two browsers are so inconsistent.  I don't want to do browser detection.
[15:43] <hatch> isn't the Ubuntu browser still like pre-alpha?
[15:43] <rick_h_> Makyo: right, but I can't easily verify without setting up adb, adding the consoles, understanding the code/etc a lot more. So wonder if for QA'ing you could add some debug/trace, ask for a QA, and we could report back some debug info as part of the QA
[15:43] <hatch> so it will come up as time goes on I would guess
[15:43] <frankban> rogpeppe: quantal bootstrap node, fake tools. Just reproduced the CharmInfo error deploying cs:precise/wordpress-11
[15:44] <gary_poster> Makyo, svg does not render, maybe only when I first log in?
[15:44] <gary_poster> I only see status circles
[15:44] <gary_poster> reloading
[15:45] <gary_poster> (I know that is not what this branch is about, just reporting :-) )
[15:45] <Makyo> rick_h_, yeah, I'll try for that in the future, or at least something like it, so long as it doesn't take up too much time (have to send the tablet out thursday morning)
[15:45] <rick_h_> Makyo: oh, :(
[15:45] <rick_h_> Makyo: hmm, so what's the long term plan for this then? I'd assumed we'd be doing this tracking/testing for a while yet
[15:45] <rogpeppe> hmm, here's a potential problem
[15:45] <Makyo> gary_poster, the rest are assets that are downloaded, and may take a second to populate the app cache.
[15:45] <gary_poster> ok
[15:46] <Makyo> rick_h_, I'll get the tablet back the week after, I believe, so we can still track, It's just this week is a little tight.
[15:46] <rogpeppe> what password-oriented hash algorithms does javascript have available
[15:46] <rogpeppe> ?
[15:46] <rick_h_> Makyo: ah, rgr
[15:46] <rogpeppe> currently we use pbkdf2
[15:46] <rogpeppe> but the client needs to calculate it before sending to the server
[15:47] <rogpeppe> and if there's no implementation in js, we'll need to choose another one
[15:48] <gary_poster> rogpeppe, hm, interesting.  Makyo or hatch, do you know anything?  Google gives me https://code.google.com/p/crypto-js/
[15:48] <rogpeppe> hmm, looks like there are a few implementations
[15:48] <rogpeppe> gary_poster: and http://anandam.name/pbkdf2/
[15:48]  * hatch pokes head in
[15:48] <gary_poster> ah yes rogpeppe
[15:49] <m_3> gary_poster: no, flushing isn't enough
[15:50] <m_3> gary_poster: it looks like jujucharms.com is incorrectly keying off of the owners :(
[15:50] <gary_poster> m_3, oh ok :-/
[15:50] <rogpeppe> gary_poster: they both look plausible
[15:50] <m_3> it might pick it up if we could delete the ~charmers branch
[15:50] <hatch> gary rogpeppe yes I have used crypto-js but only on node
[15:50] <m_3> but it's probably an actual jujucharms.com bug
[15:51] <gary_poster> the anandam seems to work fine in chrome
[15:51] <gary_poster> Makyo, guichat for a sec to help me qa?
[15:51] <rick_h_droid> m_3 what's this about juju charms. com bug?
[15:52] <gary_poster> m_3, ok.  yeah, rick_h_ will be on the team that might be able to fix it, but they might be swamped.
[15:52] <Makyo> gary_poster, brt
[15:52] <gary_poster> thanks
[15:52] <m_3> rick_h_droid: jujucharms.com/charms/precise/juju-gui should point to the same thing lp:charms/juju-gui does (i.e., owned by ~juju-gui, and not ~charmers)
[15:52] <frankban> rogpeppe: just update the MP in https://codereview.appspot.com/8566043/
[15:52] <m_3> rick_h_droid: but I'll file it as an actual bug
[15:53] <gary_poster> rogpeppe, what's the configuration we need with pbkdf2 to work with what you have now?
[15:53] <rogpeppe> gary_poster: the implementation is in trivial/password.go
[15:53] <rogpeppe> gary_poster: the salt is []byte{0x75, 0x82, 0x81, 0xca}
[15:53] <rick_h_droid> m_3 we've checked and been told time and time again that "reviewed"  == owned by charmers
[15:54] <m_3> rick_h_droid: yeah, I know... there's a huge disconnect there
[15:54] <m_3> hazmat: ^^
[15:54] <m_3> it's tips
[15:54] <rogpeppe> gary_poster: 8192 iterations, 18 bytes, using sha512, encoded as base64
[15:55] <rick_h_droid> m_3 ugh sadness.
[15:55] <rogpeppe> gary_poster: hmm, 8192 iterations takes a long time in js
[15:55] <m_3> rick_h_droid: yeah, it's probably a "list" thing
[15:56] <rogpeppe> gary_poster: like, 5 seconds
[15:56] <rick_h_droid> m_3 so what is the bit of data that says "this is reviewed and the approved root charm"?
[15:56] <gary_poster> rogpeppe, yeah, duped, 6 seconds here
[15:56] <gary_poster> 5 that time
[15:56] <m_3> gary_poster: sorry, so let me know if jujucharms.com pointing to the wrong place is a problem... the store was deploying the correct (~juju-gui) branch, so that's definitive imo
[15:56] <m_3> rick_h_droid: lp:charms/juju-gui in launchpad atm
[15:57] <gary_poster> m_3 so that means that juju deploy juju-gui deploys ~juju-gui, even though jujucharms.com says otherwise, right?
[15:57] <m_3> rick_h_droid:  but kapil and I have to figure that out before you act on anything
[15:57] <m_3> gary_poster: correct
[15:57] <m_3> (it had your no-op iirc)
[15:57] <rick_h_droid> m_3 right but in general how juju charms. com is to determine this correctly?
[15:57]  * m_3 checks again just to make sure
[15:58] <m_3> rick_h_droid: lemme look... it's launchpadlib
[15:58] <rick_h_droid> m_3 can you expand on that in the ticket you file?
[15:59] <gary_poster> jujugui call in 1
[15:59] <gary_poster> thanks m_3
[15:59] <m_3> rick_h_droid: lp_charm.setBranch(branch=charm_branch, pocket=OFFICIAL_BRANCH_POCKET)
[15:59] <m_3> rick_h_droid: but sure
[15:59] <rogpeppe> gary_poster: it takes 60ms in go...
[16:00] <gary_poster> ack rogpeppe, I don't think golang on metal and js on the browser is a fair fight :-)
[16:01] <rogpeppe> gary_poster: no indeed, but it's difficult to know where to make the compromise. we're using this alg to make it difficult to crack the password on bare metal
[16:04] <rogpeppe> gary_poster: the up-side is that i've got it to produce a matching result to the Go version
[16:04] <rogpeppe> gary_poster: by changing the go version to use sha1 as a hash and an ascii salt
[16:11] <gary_poster> (sorry on call)
[16:13] <rick_h_> m_3: right, that's 'setting' the official branch from what I'm trying to see is when jujucharms.com injests the info about a charm what's our indicator that *this* is the official charm to use
[16:23] <rogpeppe> frankban: reviewed
[16:24] <frankban> rogpeppe: thanks!
[16:24] <frankban> rogpeppe: can I consider this a +2?
[16:24] <hatch> gary_poster: do you have a minute to help me with this bug? I found out why it's happening but I don't know the best approach to solve it
[16:25] <rogpeppe> frankban: yeah, i reckon
[16:37] <m_3> gary_poster: just verified the store deploys the branch tip (i.e., ~juju-gui owned)... jujucharms.com is wrong 2-to-1 :)
[16:37] <gary_poster> m_3, heh, cool thank you
[16:37] <gary_poster> hatch, on call but will ping
[16:37] <gary_poster> rogpeppe, likewise :-) curious to see what you suggest
[16:38] <hatch> gary_poster: alright - I fixed it but I am looking for some insight so I'll propose and you can review when you have a moment
[16:47] <hatch> yes...I made it under 800ln diff
[16:47] <hatch> if just barely ;)
[16:48] <hatch> bcsaller: could I get a review on https://codereview.appspot.com/8578043/  please
[16:48] <bcsaller> hatch: of course
[16:48] <hatch> it's a big one but a lot of tests
[16:59] <bac> benji: review my blocking branch?  it turns out to be not much: https://codereview.appspot.com/8579043
[17:00] <benji> bac: sure
[17:01] <hatch> anyone else need any reviews?
[17:01] <hatch> bac: review done
[17:02] <bac> hatch: that's a very passive aggressive review
[17:03] <hatch> lol that wasn't my intentioni
[17:03] <hatch> I even put a smiley face
[17:03] <hatch> maybe it should have been a winkyfave?
[17:03] <hatch> winky face
[17:03] <hatch> :)
[17:03] <bac> hatch: was it a land-as-is or an add a test?
[17:04] <hatch> well do you think it needs a test?
[17:04] <hatch> I was just wondering how something so dramatic could be changed but it not fail any tests
[17:05] <hatch> know what i mean?
[17:07] <bac> i think a test would be appropriate.  i'm not disagreeing with that.  :)  i was just noting the confusion.
[17:08] <hatch> ohh ok - /me levels up his review descriptions
[17:08] <hatch> :)
[17:09] <bac> no how to craft such a test might be interesting
[17:09] <bac> now
[17:09] <hatch> haha yeah that I'm at a loss of as well :)
[17:11] <gary_poster> rogpeppe, thoughts on the login?  that's pretty critical.  is this not over an encrypted channel already?
[17:11] <gary_poster> the hash is double encryption afaict
[17:12] <hatch> are you talking about hashing the pw before sending it over the wire? (I have no idea of the backstory :) )
[17:12] <gary_poster> hatch yes
[17:12] <rogpeppe> gary_poster: the point of the hash is because the admin password gets sent over in the cloudinit script
[17:12] <rogpeppe> gary_poster: but...
[17:13] <gary_poster> rogpeppe, can't we send over the real password, and go hashes and compares it?
[17:13] <rogpeppe> gary_poster: well, i'll explain the rationale first
[17:13] <bac> benji: you did it too!
[17:13] <rogpeppe> gary_poster: if we send over the real password, then the real password remains around to see for anyone that is allowed to ssh into the bootstrap machine
[17:13] <benji> heh
[17:13] <gary_poster> rogpeppe, in memory?
[17:13] <bac> so we're in agreement that we wish it had a test.
[17:13] <benji> I did esplicitly say "land-as-is" though. :)
[17:13] <rogpeppe> gary_poster: on a web address
[17:14] <rogpeppe> gary_poster: (you can always retrieve the cloudinit data on a machine)
[17:14] <gary_poster> rogpeppe, no, that's not what I meamn
[17:14] <rogpeppe> gary_poster: (from that machine only, though, i think)
[17:14] <gary_poster> rogpeppe scenario is this:
[17:14] <gary_poster> password hash is sent to cloudinit
[17:15] <bac> benji: few of those app callbacks are tested.  i'll land now and think about a test after lunch when i can concentrate better.
[17:15] <benji> +1
[17:15] <hatch> good with me
[17:15] <gary_poster> for API, we send *real* password.  juju hashes it, and compares the hash against the one it received from cloudint
[17:15] <gary_poster> we don't need to hash on the browser over an encrypted channel, and hash can be kept in sync on juju side
[17:16] <gary_poster> IOW, no change to current cloudinit behavior
[17:17] <gary_poster> rogpeppe, done
[17:17]  * bac lunches and thinks deeply about tests
[17:18] <gary_poster> bcsaller, I had some thoughts on the charm but they might be idle or too late or...who knows.  Any way, I was thinking it would be nice if we could use the arbitrary tarball functionality to also let us point to CDNs.  I was thinking that we would have a configuration for specifying a tarball folder
[17:19] <gary_poster> the tarball folder would be expected to hold releases following the same naming conventions as our releases
[17:19] <hatch> oh btw I can't move onto the remove-relation until the add-relation branch lands
[17:19] <gary_poster> so you would specify the URL of the tarball folder
[17:19] <bcsaller> hatch: you can branch off it if you're willing to forward merge review changes
[17:19] <gary_poster> and then you would specify a version the way you do now
[17:19] <gary_poster> and then it would work
[17:19] <bcsaller> gary_poster: sounds good, but I'd have to look at that code more deeply to make informed comment
[17:20] <hatch> bcsaller: won't that totally screw up the diff for it's review?
[17:20] <hatch> as it's parent won't be trunk
[17:20] <gary_poster> bcsaller, would be happy to talk through if you'd like.  hatch, you need another review?
[17:20] <bcsaller> hatch: lbox propose -for lp:juju-gui will fix that down the line
[17:20] <hatch> gary_poster: yeah https://codereview.appspot.com/8578043/
[17:20] <rogpeppe> gary_poster: you're right, i think. that approach couldn't work for the mongo connection, but can work for the API connection.
[17:20] <hatch> sorry it's a big one :)
[17:21] <hatch> bcsaller: ahh
[17:21] <gary_poster> cool rogpeppe
[17:21] <gary_poster> hatch, ok on it
[17:21] <hatch> gary_poster: thanks - can you pay special attention to my modification in test/utils.js as it's functionality has now completely changed
[17:21] <gary_poster> ok
[17:22] <hatch> it being the fake charmstore
[17:22] <gary_poster> hatch, cool! that's actually what I wanted it to do when I wrote it, but I didn't need it at the time. :-)  looks good
[17:23] <hatch> ok excellent :)
[17:23] <gary_poster> hatch, why don't we subclass instead of monkeypatching though?
[17:24] <hatch> I've got nothing.... that's a better idea
[17:24] <hatch> :)
[17:25] <gary_poster> :-) ok cool, will put in review
[17:31] <rogpeppe> gary_poster: i'm not *entirely* sure it's a good idea to send the password in plaintext, even over an encrypted channel
[17:31] <rogpeppe> oops, i wanted to delete that line
[17:31] <rogpeppe> gary_poster: ignore, please
[17:31] <gary_poster> ok rogpeppe :-)
[17:31] <hatch>  /gobackintime delete
[17:31] <hatch> :)
[17:32] <gary_poster> wait, was someone talking?
[17:32] <hatch> *mohohohahaha*
[17:32] <gary_poster> :-)
[17:33] <rogpeppe> gary_poster: what i was *actually* trying to say is that we'll need a change to juju-core, because currently you create call AddUser with a password, and that stores the hash of the password in the state. i think we'll need a way of adding a new user with the already hashed password.
[17:33] <gary_poster> I see
[17:33] <gary_poster> easy, and hopefully not contentious? :-)
[17:34] <gary_poster> the number of times I've seen the japanese singer yui in google searches is funny
[17:35] <gary_poster> ooh, I have spotify!
[17:35]  * gary_poster discovers what yui sounds like
[17:35] <rogpeppe> gary_poster: spotify is awesome
[17:35] <gary_poster> +1!
[17:36] <hatch> haha
[17:36] <rogpeppe> gary_poster: this was the weirdest thing i heard today: http://open.spotify.com/track/2k3CKmu9LND5bwi2ENnhog
[17:36] <hatch> no spotify in Canada :(
[17:37] <gary_poster> rogpeppe, lol that's awesome! musically adventurous klezmer, or something like that!
[17:37] <gary_poster> sadly yui's music is not my thing
[17:38] <rogpeppe> gary_poster: unclassifiable!
[17:38] <gary_poster> :-)
[17:38] <gary_poster> my favorite
[17:38] <hatch> holy! a passing CI test
[17:38]  * hatch goes to buy a lottery ticket
[17:38] <hatch> yeah...I went there :P
[17:39] <rick_h_> hatch: buy one for me!
[17:39] <gary_poster> :-)
[17:39] <hatch> hah
[17:39] <rogpeppe> gary_poster: i found it by clicking musician links from a scandi folk/experimental band
[17:40] <gary_poster> rogpeppe, reminds me of some contemporary classical composer that I'm having trouble remembering...
[17:41] <rogpeppe> gary_poster: this was the band i got to it from (i actually saw them when we were in copenhagen - a friend was depping for them on the piano) http://open.spotify.com/album/4PkoB95HnTBDomlhoQJVxi
[17:44] <gary_poster> that's pretty good, rogpeppe .  fwiw composer was kernis http://open.spotify.com/track/6eYyd2wDS6AwCfQvJdC7aG (I love his musica celestis string quartet fwiw)
[17:45] <hatch> and there goes the CI, I knew I spoke too soon
[17:46] <gary_poster> :-)
[17:46] <rogpeppe> gary_poster: cool.
[17:46] <rogpeppe> gary_poster: that goes into my "to listen to" list
[17:46] <gary_poster> cool, yours too
[17:47] <rogpeppe> gary_poster: which has everything that i happen to hear or hear about that sounds awesome
[17:47] <gary_poster> :-)
[17:47] <rogpeppe> gary_poster: too much to listen to: spotify:user:rogpeppe:playlist:7KEnRbQD0KNXdI4AE2f9OG
[17:48] <gary_poster> rogpeppe, that's eclectic!  I like it!
[17:48] <rogpeppe> gary_poster: i generally exclude classical and heavy metal into other playlists 'cos they don't work well when played on random
[17:48] <gary_poster> can see that
[17:48] <hatch> bcsaller: I don't understand two comments in fakebackend.js "point of consideration" and "directly asserting these code paths"
[17:48] <hatch> can you elaborate a bit
[17:54] <rogpeppe> i've reached eod here. g'night all. authentication enabled tomorrow...
[17:54] <rogpeppe> gary_poster: see ya
[17:54] <bcsaller> hatch: the pyjuju code doesn't mutate the stored charms to test juju-info, its added when asking the mayReleateTo question
[17:54] <gary_poster> cool rogpeppe have a good night
[17:54] <bcsaller> hatch: as for 'directly' I mean invoke and test the fakebackend w/o involving the sandbox, call the methods directly as unittests to be sure they work in isolation
[17:55] <bcsaller> hatch: for a branch of that side to add nothing to test_fakebackend was scary :)
[17:56] <bcsaller> s/side/size
[17:56] <gary_poster> +1 on specific tests to test_fakebackend
[17:56] <gary_poster> sandbox tests should be reserved to the code specific to that integration, in a perfect world
[17:57] <hatch> alright will do
[17:57] <bcsaller> I don't always get that divide correct either, but zero is an easy one :)
[17:57] <gary_poster> :-)
[17:58] <hatch> yeah I'll add direct unit tests although I don't think that anything other than 'charm:interface' is supported
[17:59] <hatch> as far as the inferred relation is concerned
[17:59] <hatch> at least I didn't find anything in the UI that would send that type of data
[18:00] <hatch> or is that a feature of the pyjuju backend that I didn't notice?
[18:01] <bcsaller> hatch: the cli works that way so someone missed it
[18:01]  * gary_poster doesn't know what hatch is talking about.  he just would prefer most tests to be for fakebackend, when possible
[18:02] <hatch> bcsaller: alright I'll add that functionality as it will fail right now
[18:02] <hatch> and yes gary I'll add tests to the fakebackend :D
[18:03] <gary_poster> :-) thank you
[18:05] <Makyo> Dang, missed the music talk.
[18:17] <gary_poster> hatch, great work.  Lot's of comments.  Lemme know if you have any questions, and if you doubt what I said please do double check with Ben
[18:18] <hatch> thanks I'll read now
[18:18]  * gary_poster needs some lunch.  breaking now
[18:18] <gary_poster> Lots of tests, I should say. :-P
[18:18] <gary_poster> I mean Lots of comments.   I have ran into it a number of times today and just wondering if it's something with mocha or my system
[19:05] <rogpeppe> hatch: could you have a look too, please?
[19:05] <hatch> rogpeppe: NSFW? :P
[19:05] <gary_poster> rogpeppe, nothing
[19:05] <benji> hatch: does it ever time out or is it a total freeze?
[19:05] <gary_poster> I mean, no services
[19:05] <rogpeppe> gary_poster: right, that's weird
[19:05] <gary_poster> agree, it should show gui at least
[19:05] <benji> (we have seen timeouts recently, at the sprint and just after; we raised the timout and they went away)
[19:06] <hatch> no services here either
[19:06] <hatch> Uncaught Developers must initialize charms with a well-formed id. service.js:832
[19:06] <hatch> benji: it ust stops, doesn't hang, just goes back to the prompt
[19:06] <hatch> so it's timing out?
[19:07] <rogpeppe> gary_poster: i ran jujuwatch on the API server and saw this, which looks ok (although i haven't looked in detail) : http://paste.ubuntu.com/5693311/
[19:07] <benji> I can't remember for sure, but that may be timing out.  I would bump the timeout and see.
[19:07] <gary_poster> rogpeppe, the error means that the charm id does not match the regex we expect
[19:07] <gary_poster> looking
[19:08] <rogpeppe> hatch, gary_poster: i was about to destroy the environment over night, but thought i'd demo carmen the fancy new GUI first
[19:08] <rogpeppe> demo effect FTW
[19:08] <benji> the timeout is in test-server.sh, the -t option to mocha
[19:08] <gary_poster> :-) ok, two charms, lemme try runnung those through the regex
[19:08] <gary_poster> they look fine on the face of it
[19:08] <hatch> benji: alright I'll give that a go
[19:08] <rogpeppe> FWIW it was working on the same environment earlier
[19:08] <rogpeppe> hatch: do you want me to leave the environment going?
[19:09] <hatch> rogpeppe: nope you can kill it
[19:09] <rogpeppe> hatch: ok, will do, thanks
[19:09] <hatch> am I supposed to know who Carmen is?
[19:09] <hatch> :)
[19:10] <gary_poster> darn
[19:10] <gary_poster> hatch you spoke too soon :-P
[19:10] <gary_poster> the id is not being passed to the charm
[19:10] <hatch> aww crud
[19:10] <gary_poster> it is empty
[19:10] <hatch> sorry :)
[19:11] <gary_poster> can't determine whybecause sources are gone
[19:11] <gary_poster> we can repro easily enough, I suspect
[19:11] <gary_poster> jcsackett, awesome thank you.  I'll see if I can land my branch now...
[19:16] <gary_poster> hatch, all tests pass in the testclean branch now, after jc's removal of the slider
[19:16] <gary_poster> proposing
[19:16] <hatch> w00t w00t
[19:20] <hazmat>  just removed charmers from ~juju-gui not sure why they were there.
[19:20] <hatch> man I wish we could do `[a, b] = myFunction();` in js
[19:21]  * hatch hopes for ES6 to come soon
[19:21] <hatch> :)
[19:21] <gary_poster> hazmat, they were there because m_3 requested it as part of converting the !juju-gui charm to be the official one
[19:21] <gary_poster> ~juju-gui
[19:21] <hazmat> gary_poster, thanks. i'll follow up
[19:22] <gary_poster> welcome
[19:23] <hatch> do I get any points for making code lines exactly 80chars?
[19:23] <gary_poster> 80 points, hatch!
[19:24] <hatch> w0000t!
[19:25] <hatch> the grader is making a mess of my block spreading the snow out to melt faster
[19:25] <gary_poster> what is this "snow" of which you speak?
[19:27] <hatch> haha - 4ft pile of white stuff on my lawn after 2 weeks of melt
[19:29] <hatch> this year we got a huge amount of snow - so many peoples houses are getting flooded
[19:29] <gary_poster> wow
[19:29] <hatch> I learnt many years ago to shovel the snow away from the house/garage come spring
[19:29] <hatch> it's a ton of work, but a lot less work than replacing walls/carpet
[19:30] <gary_poster> yeah, I bet :-(
[19:32] <gary_poster> review request for branch that makes our tests more robust, from me and hatch.  paired branch, so we only need one reviewer :-) https://codereview.appspot.com/8580046
[19:32] <gary_poster> from hatch and me, I hasten to add, lest my children hear me speak ungrammatically
[19:33] <hatch> isn't it "from hatch and i"
[19:33] <gary_poster> no
[19:33] <gary_poster> from me
[19:33] <gary_poster> so "from hatch and me"
[19:33] <gary_poster> my parents were English teachers, can you tell?
[19:33] <gary_poster> :-P
[19:34] <hatch> haha - I'll accept that you're probably right but I was sure that would be 'I' instead of 'me'
[19:34] <gary_poster> :-)
[19:37] <hatch> 12 comments down....13 more to go
[19:37] <hatch> then onto tests :P
[19:37] <gary_poster> :-) thank you
[19:37] <hatch> the reviews were good so I'm not complaining
[19:38] <hatch> nothing in there that doesn't make it better code
[19:38] <hatch> so happy to do it :)
[19:38] <gary_poster> cool
[19:39] <hatch> I also just found the 'Done' button
[19:40] <gary_poster> :-)
[19:42] <hatch> bcsaller: can you weigh in on the possibility of having a charm relate to itself?
[19:44] <gary_poster> hatch you mean a service relate to itself I think, but kinda the same
[19:45] <gary_poster> similar anyway :-)
[19:45] <hatch> er yes
[19:45] <hatch> 	 546       if (epAData.name [19:45] <hatch>  547         return {error: 'Endpoints must be different.'};
[19:45] <hatch> for your comment on that check
[19:45] <gary_poster> yeah, thank you
[19:48] <gary_poster> Thank you for the review Makyo :-)
[19:48] <Makyo> gary_poster, np.  Finishing up testing and such on the touch branch now that it's up to date with trunk.  Should I merge it with one LGTM and a bug about android?
[19:49] <gary_poster> Makyo...sure. :-)
[19:50] <Makyo> gary_poster, alright. Just want to see what else I can get to before ODS.
[19:50] <gary_poster> yes, +1
[19:50] <hatch> gary_poster: we should probably have a card for Friday to educate the others on the changes in the testclean branch
[19:51] <gary_poster> hatch +1
[19:51] <gary_poster> and a quick blog post or email or something' will do
[19:51] <gary_poster> looks like our landscape integration is gebroken on trunk :-(
[19:52] <hatch> card made
[19:53] <gary_poster> thanks hatch
[19:53] <gary_poster> uh=oh
[19:54] <gary_poster> unexposing does not update environment properly either :-(
[20:16] <hatch> lol gary_poster I love the "when Canonistack isn't doing that for us" comment
[20:16] <hatch> I lol'd
[20:16] <gary_poster> juju:-)
[20:17] <gary_poster> mm, the "juju" was an aborted comment from before :-P
[20:17] <hatch> haha
[20:32] <gary_poster> computer is being weird, so restarting
[20:44] <hatch> bac: lol best review comment
[20:45] <bac> hatch: it was truthful
[20:45] <hatch> agreed
[20:51] <gary_poster> two greens in a row on CI.  what is the world coming to?
[20:53] <benji> heh
[20:53] <hatch> lol
[20:53] <hatch> bcsaller: you back yet?
[20:53] <hatch> gary_poster: I'd be interested to see if our changes stop those retries from happening
[20:54] <gary_poster> me too
[20:54] <benji> slightly more picky yuidoc linter is in, along with the 700 line diff to shut it up; the real monster is commented out pending our fight^Wdiscussion Friday
[20:54] <gary_poster> :-)
[20:54] <gary_poster> we have a nice setAnnotations method that nobody is using...
[20:55] <gary_poster> oh wait yes they are
[20:55] <gary_poster> in fakebackend
[20:56] <benji> if we change our yuidoc comment style the diff will be around 5000 lines, but will be pretty easy to generate programmatically
[20:57] <hatch> I think it looks better without the *'s
[20:58]  * gary_poster too
[20:58]  * gary_poster should be quieter :-P
[20:58] <hatch> haha it's ok I think we are all way to oppinionated to be swayed that easily :P
[20:59] <benji> I think it looks better with them.  I think it works better without them (indentation is sainer and less fiddly hand-editing when wrapping, fixing conflicts, etc.)
[20:59] <gary_poster> heh yeah, hatch
[20:59] <hatch> haha benji it sounds like you are torn inside about it
[21:00] <benji> heh; not really, I'm on team function not team form
[21:00] <gary_poster> argh!!!! chromeis not making me happy
[21:01] <benji> "chromies" are friends who are made out of metal
[21:01] <gary_poster> :-P
[21:03]  * benji updates his Guide to Made Up Etemology
[21:04]  * benji also updates his Guide to Speling Words Almost Correctly
[21:05] <gary_poster> ok, who is going to join me in guichat and prevent me from cursing at chrome
[21:05] <gary_poster> ideally by helping me figure out what the heck is going on :-P
[21:06] <benji> gary_poster: I have a minute.
[21:06] <gary_poster> thanks, joining
[21:10] <gary_poster> I is here
[21:10] <gary_poster> and in guichat, benji
[21:10] <benji> gary_poster: I think I'm there too.  :) let me check
[21:21] <hatch> I think we need a combined but not minified version of prod
[21:21] <hatch> so when we get prod only errors we can debug them
[21:30] <gary_poster> hatch we have sourcemap
[21:30] <hatch> I just threw in debugger statements
[21:32] <hatch> somehow I managed to break Y.juju.Charmstore
[21:33] <gary_poster> Makyo, do yoy happen to know why we have to convert annotation keys from hyphens to underlines>?
[21:33] <gary_poster> must run but that's source of landscape bug
[21:33] <gary_poster> biab
[21:34] <Makyo> gary_poster, I think that's a question for frankban. I don't know that we need to.
[21:48] <Makyo> Finally!  NB, guihelp, must make clean for test-prod to pass, with a recent merge.
[21:48] <hatch> oh yeah....woops we forgot to mention
[21:48] <hatch> :)
[21:48] <hatch> blame gary cuz he is away and can't defend himself
[21:49] <Makyo> I'll blame myself for not thinking to try that sooner :)
[21:49] <hatch> it's ok, I Just spent 10 minutes trying to track down a bug which was actually me thinking I Had merged in our test fixes but I hadn't
[21:49] <hatch> *facepalm*
[21:56] <hatch> Makyo: are you familiar with how the relationship code is supposed to function?
[21:56] <Makyo> hatch, here and there, yeah.  The drawing code, at least.
[21:57] <hatch> alright I'm actually trying to figure out how to implement the juju-info implicit relation stuff
[21:57] <hatch> know anything about that?
[21:58] <Makyo> Alas, no.   At least, I've not heard of it before.
[22:00] <hatch> alright np I'll wait for Ben to come back as this stuff has way to many conditionals that aren't spelled out very well
[22:01] <bcsaller> hatch: oops, did I miss something?
[22:01] <bcsaller> hatch: ahh, something related to itself is a peer relationship
[22:02] <hatch> yeah I remembered that after a while :)
[22:02] <hatch> so I removed that check
[22:02] <hatch> but the thing that doesn't make any sense are the Inferred relations
[22:02] <hatch> how is that even allowed?
[22:02] <hatch> two charms could relate on multiple levels
[22:02] <hatch> so not requirng the interface is just asking for complications
[22:03] <bcsaller> that happens all the time, we have code to allow for the resolution of ambiguous relations
[22:03] <hatch> how does it know what to pick?
[22:03] <bcsaller> there is a menu that pops up when its possible to relate on more than one interface
[22:03] <bcsaller> you have to pick or be more specific
[22:03] <hatch> oh...I've never seen this
[22:03] <bcsaller> on the cli we list the options and they have to add :whatever
[22:03] <hatch> that will have to be implemented into this backend too
[22:03] <bcsaller> in the gui we pop up a menu
[22:04] <Makyo> Oh, I see what you mean.
[22:05] <hatch> ok I think that we need to cut the features of this branch down so it can be landed
[22:06] <hatch> adding support for inferred relations is going to be a whole other amount of work I'm thinking
[22:07] <hatch> oh that's already handled by the GUI
[22:07] <hatch> that's not a backend thing
[22:07] <hatch> unless the backend needs to support it as well
[22:19] <hatch> bcsaller: can two charms neither of which aren't subordinates have a juju-info relation?
[22:26] <bcsaller> hatch: they could. for example a monitoring tool might not need filesystem level access
[22:27] <hatch> ok so if they have no matches on any interface the default is to match them on juju-info?
[22:28] <hatch> so assuming `juju add-realtion foo bar`
[22:28] <hatch> and foo and bar have no shared interfaces
[22:28] <hatch> and neither are subordinates
[22:28] <hatch> are they automatically connected on the juju-info?
[22:29] <hatch> or do at least one of them have to require it?
[22:29] <Makyo> hatch, I think they are automatically connected if the relation isn't ambiguous (that is, there is only one possible relation type)
[22:29] <rick_h_droid> sinzui can you invite me to the hangout please? I'm on mobile
[22:30] <hatch> Makyo: well the issue is that we automagically add juju-info regardless
[22:30] <hatch> and those rules aren't specified....at least not in enough detail
[22:31] <hatch> if I'm reading the docs correctly
[22:31] <hatch> we are only supposed to implicitly add it to the 'provides' so at least one of them needs it in their 'requires'
[22:31] <hatch> https://juju.ubuntu.com/docs/implicit-relations.html
[22:32] <Makyo> hatch, ooh, yeah...wandering out of familiar territory for me.
[22:32] <Makyo> Is it able to make up its own branch?
[22:32] <hatch> Makyo: it depends on how deep the rabit hole goes :D
[22:33]  * hatch doesn't like automagic code
[22:33] <Makyo> Well, FWIW, I'm all for landable branches.  If there's a way to separate this, I think another card would be fine.
[22:34] <hatch> well I'm still writing some tests so I'm not blocked yet :)
[22:34] <Makyo> Alright.
[22:35] <Makyo> If you hit blocked status, I say re-evaluate.
[22:35] <Makyo> It's James' birthday, so I'm going to run to the store real quick and grab flowers and such.    Flowers, cream for the pasta sauce, stuff for drinks, and dog food (unrelated)
[23:09] <hatch> or.....related
[23:09] <hatch> NSFW!
[23:10] <Makyo> He can have the dogfood, then, I'll take the pasta in mushroom sauce :)
[23:10] <Makyo> With truffle oil, if I can figure out how much.
[23:11] <hatch> haha
[23:11] <hatch> I don't even know what truffle oil is
[23:11] <hatch> I thought truffles were mushrooms
[23:11] <Makyo> Cheaper than truffles, that's for sure.
[23:11] <hatch> lol
[23:12] <Makyo> Just olive oil that's had truffles soaked in it.
[23:12] <Makyo> Still really strong.
[23:12] <hatch> ohhh gotcha - I don't think I have ever had it
[23:15] <hatch> :/ these tests are still stopping part of the way through
[23:16] <rick_h_> hatch: does yui have any date helpers. Seems stupid I can't get a month name for a date :/
[23:16] <rick_h_> ooh, Date.format
[23:16] <hatch> rick_h_ Date.format
[23:16] <hatch> :)
[23:16] <hatch> I think it's also allows internationalization
[23:18] <rick_h_> hmm, must be why it wants an obj second param vs just a string
[23:18] <rick_h_> fugly api
[23:21] <hatch> bcsaller: gary_poster I have to take off but I wanted to propose my changes in hopes that I could land it as an intermediary branch and then implement the inferred interface stuff in the morning
[23:22] <bcsaller> hatch: cool, I can take a peek later
[23:22] <hatch> thanks
[23:23] <hatch> I'll be on in a few hours but untill then, have a good night everyone
[23:25] <rick_h_> see ya hatch


[00:28] <wallyworld> veebers: reviewed, a couple of questions, see what you think
[00:56]  * veebers looks
[01:02] <veebers> wallyworld: have responded, essentially they're all good points I'll make the change. I did respond re: the status-log question though as it needs further comment.
[01:05] <babbageclunk> wallyworld: that seems to work fine for the ifPrimaryController! Unfortunately the other use of the singular worker is in the model manifolds - it's not so simple to get rid of that one without actually implementing leases, or else running a set of raft workers in each model. :(
[01:27] <wallyworld> veebers: sorry, was eating, looking now
[01:30] <wallyworld> babbageclunk: well that sucks. those model workers ultimately run on a controller. i wonder if there's a way to gate their startup in the engine definition somehow. not sure off hand
[01:34] <wallyworld> veebers: makes sense, thank you, left a couple of comments
[01:38] <babbageclunk> wallyworld: Yeah, I think we could feed the state of the raft-leadership flag from the machine manifolds into the model manifolds, but then that would have the effect of making all those workers run on the machine that was the raft leader, which I don't know that we'd want.
[01:39] <wallyworld> babbageclunk: that may be true. i guess we want them spread around a bit
[01:40] <wallyworld> babbageclunk: maybe use a separate named raft fsm for that :-)
[01:40] <wallyworld> or just use the lease fsm or something
[01:48] <babbageclunk> Yeah, it seems like just exposing the lease store would do it.
[01:53] <veebers> wallyworld: hah no worries; eating is way more important than my PR ^_^ have made the suggested changes and all pushed up.
[01:54] <veebers> wallyworld: you mentioned a site that had details re: tomb.v2 -> tomb.v3, is that just github and release notes or is there something more substantial?
[01:55] <wallyworld> veebers: v1->v2. not sure off hand, i know there's a home page somewhere
[01:55] <wallyworld> maybe just gh
[01:56] <veebers> wallyworld: ack, I'll have a look. cheers
[02:00] <wallyworld> veebers: bug 1745031 is fix committed now right?
[02:00] <mup> Bug #1745031: gce add credentials "Enter file" absolute path msg improvment <juju:In Progress by veebers> <https://launchpad.net/bugs/1745031>
[02:04] <veebers> wallyworld: aye it is, I'll update status
[02:05] <wallyworld> ta, and move card
[02:05] <veebers> card is done, forgot to update bug :0
[02:20] <wallyworld> veebers: tiny one https://github.com/juju/juju/pull/8623
[02:20]  * veebers looks
[02:23] <veebers> wallyworld: LGMT, have made a suggestion on it
[02:23] <wallyworld> ok, ty
[02:23] <wallyworld> veebers: would $PROJECT_DIR work?
[02:24] <wallyworld> i should just try it
[02:27] <veebers> wallyworld: I don't think so, because it's using PROJECT which is a relative path, really just the project name
[02:28] <wallyworld> veebers: i just tried it and it seemed to work.       $make -C /home/ian/juju/go/src/github.com/juju/juju pre-check
[02:28] <wallyworld> where i was in some other dir
[02:28] <thumper> wallyworld: have you confirmed that make check fails if go vet isn't happy?
[02:28] <wallyworld> yes of course!
[02:28] <veebers> wallyworld: oh cool, ah right go list is probably smart about what the project is and knows GOPATH etc.
[02:28]  * thumper is now in the coffee shop up the road
[02:29] <wallyworld> veebers: yeah i think so
[02:29] <veebers> thumper: if the house wasn't a total madhouse I would invite you up so you could consume our power and internet
[02:29] <thumper> wallyworld: have you got a link to the release notes for 2.4?
[02:29] <thumper> veebers: that's fine, getting coffee while I'm here, have the kids too
[02:29] <wallyworld> thumper: https://docs.google.com/document/d/1kz1NGMEeHdmSMs3PSxsDVej_tR4bjyAIcRWyx0UwohE/edit
[02:32] <vino> wallyworld: have a min
[02:32] <wallyworld> sure
[02:32] <wallyworld> standup ho
[02:32] <vino> hangout
[02:32] <vino> ok.
[02:35] <veebers> babbageclunk: you seen or used magithub? (https://github.com/vermiculus/magithub)
[02:38] <veebers> wallyworld: to confirm, for the resolve test do you still want to use show-status-log to confirm hook execution?
[02:48] <wallyworld> veebers: i reckon that could maybe be overkill?
[02:48] <wallyworld> seems the charm behaviour helps verify it's all correct
[02:50] <veebers> wallyworld: agreed, sorry was a bit confused by PR comments. It seems you where asking that again. I'll leave as is using charm, no log check
[02:50] <wallyworld> veebers: i  may not have been clear
[02:51] <wallyworld> +1 to using charm
[02:52] <veebers> mean, I'll merge now then :-)
[02:55] <babbageclunk> veebers: ooh, no I have not
[02:57] <kelvinliu_> wallyworld: I think bug  https://bugs.launchpad.net/juju/+bug/1764649 is not a juju bug but a `interface-mysql` bug
[02:57] <mup> Bug #1764649: juju caas remove-relation does not work <juju:New for wallyworld> <https://launchpad.net/bugs/1764649>
[02:57] <thumper> wallyworld: there was something we were talking about recently that we wanted to add to charms metadata.yaml, do you recall what it was?
[02:58] <thumper> we have a request to add some charm-version info
[02:58] <thumper> but if we were going to modify metadata.yaml I'd like to get both changes in at once
[02:59] <wallyworld> thumper: hmmm, yeah i do recall something, i think it was a version field for when charms supported application level data bags
[03:00] <thumper> what would that version be used for?
[03:00] <wallyworld> kelvinliu_: i don't think the mysql charm for IAAS clouds has the same issue? or does it?
[03:00] <thumper> the charm-version I'm thinking about relates to charm releases
[03:00] <thumper> like adding "pike" for keystone
[03:00] <thumper> or something
[03:01] <wallyworld> thumper: so a v2 charm would support X whereas V1 would not. that's different to your version
[03:01] <wallyworld> maybe we need a capabilities list
[03:01] <wallyworld> like series
[03:01] <wallyworld> a charm supports "app data bags" and ....
[03:01] <thumper> hmm...
[03:02] <thumper> I know there was one where we wanted to add lxd devices to pass through etc
[03:02] <kelvinliu_> wallyworld: remoteUnitName will be empty for non relation hook or relation-broken hook from juju side. So in `relation-broken hook` handler, we can't access `self.conversation()` unless the `scope` of the `Relation class in provides.py` set to `scopes.GLOBAL`
[03:02] <wallyworld> thumper: yeah, that rings a bell too
[03:02] <thumper> wallyworld: I'm going to make a quick doc for charm metadata updates
[03:03] <thumper> so we can have one place...
[03:03] <wallyworld> kelvinliu_: oh, i see, i didn't realise remote unit name was empty for relation-departed
[03:03] <kelvinliu_> wallyworld: but the scope of `interface-mysql` is set to `scopes.SERVICE`
[03:03] <wallyworld> thumper: yup
[03:04] <wallyworld> kelvinliu_: i wasn't sure what it was set to. i think service scope has different behaviour in getting the conversation
[03:04] <kelvinliu_> kelvinliu_: `remoteUnitName` is empty for `relation-broken`, `relation-departed` is fine.
[03:05] <kelvinliu_> wallyworld:`remoteUnitName` is empty for `relation-broken`, `relation-departed` is fine.
[03:05] <wallyworld> hmmm, i wonder why that is. i might need to go and read the uniter code
[03:05] <wallyworld> there must be a reason that someone had, but it seems the mysql charm expects it
[03:05] <wallyworld> to not be empty
[03:10] <kelvinliu_> wallyworld: i guess, when we got `relation-broken` event triggered, we may lose the remote unit context in this case. So the context of remote unit will be not guaranteed to be there.
[03:10] <wallyworld> kelvinliu_: just saw this in some doc: The "relation-broken" hook is not specific to any unit, and always runs once when the local unit is ready to depart the relation itself
[03:11] <wallyworld> i have to check code, but it does seem relation-broken hook does not set remote unit
[03:11] <wallyworld> hence the charm interface layer is wrong
[03:11] <wallyworld> i'm quickly testing on an iaas model to confirm
[03:12] <kelvinliu_> wallyworld: yes, I changed `'{provides:mysql}-relation-{broken,departed}'`  to `'{provides:mysql}-relation-departed'`, and `juju resolved mysql/0` is resolved successfully
[03:13] <wallyworld> kelvinliu_: so it seems we don't even want to run the relation broken hook
[03:15] <wallyworld> we would look to do a PR against the mysql interface layer if we 100% confirm the right thing is to skip the broken hook
[03:20] <kelvinliu_> wallyworld: if do need to run `relation-broken`, we have to parse `scope` manually to get the `correct conversation`.
[03:24] <wallyworld> kelvinliu_: so i checked the standard mysql charm. it is not a reactive charm. it uses relation broken to revoke all privileges for the user
[03:25] <wallyworld> we should check bugs filed against the reactive interface layer to see if its a known issue
[03:26] <kelvinliu_> wallyworld: yes, I am looking
[05:34] <wallyworld> jam: forgot - you and manadart need to update 2.4 beta1 release notes for tomorrow's release
[05:34] <jam> wallyworld: ack
[05:44] <wallyworld> kelvinliu_: how goes it with mysql interface layer. do you think we could do a patch and fork the code?
[05:52] <manadart> wallyworld: Ack.
[06:16] <kelvinliu_> wallyworld: to make it working, we will just make the handler to listen `departed` event. I just read all the other interface repos, I only see `relation-broken` handlers if the scope sets to `GLOBAL`. from what I read from the code, `remote unit name` is required for non `GLOBAL scope.`
[06:18] <kelvinliu_> wallyworld: we probably should set the scope to `GLOBAL` to handle the `relation-broken`.
[06:19] <wallyworld> kelvinliu_: sounds right i think
[06:21] <wallyworld> kelvinliu_: the author of the layer is cory who works for canonical. if you could do a patch and put up a PR, we can get him to look at it
[06:21] <wallyworld> raise a bug and link the PR to the bug
[06:22] <wallyworld> https://github.com/johnsca/juju-relation-mysql
[06:22] <kelvinliu_> wallyworld: I saw you set the scope to `GLOBAL` actually. But it seems the interface includes in `layer.yaml` did not use the local interface version at `./deps/interface/juju-relation-mysql`. I am reading to the docs to see how to fix this
[06:23] <wallyworld> i'm not overly familiar with the detail of the reactive layers here
[06:24] <wallyworld> at EOD today, you could raise a bug with as much detail as has been discovered in the bug and cory should see that when he starts
[06:24] <wallyworld> he's in US timezone
[06:26] <kelvinliu_> wallyworld: i was reading this https://github.com/juju-solutions/interface-mysql-root    not sure how did `charm` know which one to download 'interface:juju-relation-mysql'
[06:26] <kelvinliu_> wallyworld: yes, I will do that, thx
[06:26] <wallyworld> kelvinliu_: yeah, that's not the one the charm uses. maybe that one is more suitable
[06:27] <wallyworld> i'd need to look
[06:27] <wallyworld> the charm knows which one to use because it's in a layers file, i'll look it up
[06:27] <wallyworld> kelvinliu_: see layes.yaml
[06:27] <kelvinliu_> where did u get this ./deps/interface/juju-relation-mysql from?
[06:27] <wallyworld> layers.yaml
[06:28] <wallyworld> in the root dir of the mysql charm
[06:28] <wallyworld> charm build uses this layers file
[06:28] <wallyworld>  ./deps/interface/juju-relation-mysql is put there by charm build
[06:28] <wallyworld> based on layers.yaml
[06:30] <kelvinliu_> ic
[06:30] <wallyworld> kelvinliu_: that mysql-root one is not what we want
[06:30] <wallyworld> it's for the admin db
[06:31] <kelvinliu_> wallyworld: in the r`equires.py`, the scope is set to `GLOBAL`. donot know why they are different.
[06:32] <wallyworld> kelvinliu_: that's for the requires side
[06:40] <wallyworld> kelvinliu_: sorry, had someone at door. the bit that is failing here is on the providers side, the mysql end
[06:44] <kelvinliu_> wallyworld: would you give more details?
[06:45] <wallyworld> relations have a requires end and a provides end
[06:45] <wallyworld> mysql defines an interface that is the provides end
[06:46] <wallyworld> the logic for that is in provides.py
[06:46] <wallyworld> you can look at the charm metadata.yaml file to see the endpoints
[06:46] <kelvinliu_> ah, ic. so the requires.py -> gitlab, provides.py -> mysql, in this case
[06:46] <wallyworld> yup, that's it
[06:47] <kelvinliu_> more clear now, thx
[06:47] <wallyworld> and the reactive framework plugs in the requires vs provides bit of that mysql interface layer
[06:50] <kelvinliu_> ic. so the problem is provides/mysql can't get the remote name(`gitlab`) to get the correct conversation when the scope sets to `service` for event `relation-broken`.
[07:04] <kelvinliu_> wallyworld: created this issue here, https://github.com/johnsca/juju-relation-mysql/issues/3   plz let me know if you have more questions, thx
[07:07] <wallyworld> kelvinliu_: bug report looks ok, i'll just make a small correction - "operator" is a caas specific term which is not widely in use
[07:07] <wallyworld> kelvinliu_: i can't edit, can you change operator to "uniter hook runner"
[07:09] <kelvinliu_> wallyworld: updated, thx for the correction.
[07:09] <wallyworld> great ty
[07:11] <wallyworld> kelvinliu_: next steps include adding CI test coverage for caas deployments
[07:16] <kelvinliu_> wallyworld: yup, should I create a card on A team board for this?
[07:23] <wallyworld> kelvinliu_: yes please
[07:24] <wallyworld> kelvinliu_: we can talk more tomorrow with chris on how to get started. all the CI code is in the source tree
[07:25] <wallyworld> in the acceptancetests dir
[07:27] <kelvinliu_> wallyworld: ok, thx. let's talk this tmr morning
[07:27] <wallyworld> kelvinliu_: sounds good
[07:37] <manadart> I have added release notes for the new controller config options for spaces. Subject to editorial intervention :)
[20:38] <veebers> Morning o/