[00:00] <hatch> can do!
[00:00] <gary_poster> hatch, after that, expose and unexpose would be easy things to do, I bet.
[00:00] <hatch> alright assigned
[00:01] <gary_poster> cool, thank you!  honestly, the only thing particularly tricky there that I see is the annotations, and that is just because we will need to hook up annotation deltas
[00:01] <gary_poster> but that should also follow existing patterns
[00:03] <hatch> sounds good
[09:15] <frankban> morning rogpeppe: does juju-core trunk compile for you? I see cmd/builddb/main.go:9: imported and not used: "launchpad.net/juju-core/state"
[09:15] <rogpeppe> frankban: i see that too. it should be fixed.
[09:15] <rogpeppe> frankban: nothing depends in builddb though, i don't think, so it's not critical
[09:17] <frankban> rogpeppe: doesn't it prevent juju-core to be "go install"ed?
[09:17] <rogpeppe> frankban: no. just builddb
[09:18] <frankban> rogpeppe: ok
[09:20] <frankban> rogpeppe: unrelated, what's your plan on including constraints and settings in the allwatcher? is there anything I can do to help implementing it?
[09:21] <rogpeppe> frankban: i guess the only thing to do is add new Info types and add their collections to the set of collections watched
[09:21] <rogpeppe> frankban: it's a bit weird that constraints are in their own collection
[09:21] <rogpeppe> fwereade__: why are constraints in their own collection?
[09:21] <frankban> rogpeppe: because constraints are only related to units?
[09:24] <rogpeppe> frankban: no, constraints are related to units, services and machines
[09:25] <rogpeppe> frankban: the difficulty is that neither constraintsDoc nor settingsDoc hold the entity name in the doc
[09:26] <rogpeppe> frankban: well, actually there's no settingsDoc per sre
[09:26] <rogpeppe> s/sre/se/
[09:26] <frankban> rogpeppe: yes, the tag
[09:29] <frankban> rogpeppe: AFAICT constraints include the global key (pk) and settings something else (e.g. serviceSettingsKey)
[09:30] <rogpeppe> frankban: yes - i think the service settings key is to allow charm upgrades
[09:30] <rogpeppe> frankban: but i don't know much of the detail
[09:31] <frankban> rogpeppe: so we need a way to include the entity tag in both docs
[09:32] <rogpeppe> frankban: yeah, that's probably the easiest way forward. but might not go down well. i'm having another look at adding a level of indirection.
[09:32] <frankban> rogpeppe: cool, thanks
[09:33] <fwereade__> rogpeppe, frankban, hey, sorry
[09:33] <frankban> morning fwereade__ 
[09:34] <fwereade__> rogpeppe, frankban: basically they're in their own collection because they're conceptually distinct from the various entities and they're not fundamental to the operation of the entities in question
[09:34] <fwereade__> rogpeppe, frankban: consider also settings
[09:35] <rogpeppe> fwereade__: aren't they attributes of the entities in question?
[09:35] <fwereade__> rogpeppe, I'm not sure there's anything strongly indicating that they must be
[09:35] <rogpeppe> fwereade__: it seems a bit weird that you can do Service.Watch but you don't see the service constraints change
[09:36] <rogpeppe> fwereade__: well, we could have every attribute in its own collection
[09:36] <rogpeppe> fwereade__: i'm not sure that would be good though
[09:36] <fwereade__> rogpeppe, well, I'm not proposing that...
[09:37] <rogpeppe> fwereade__: i'm not sure what you think is good about having attributes of an object spread across separate collections.
[09:40] <fwereade__> rogpeppe, well, it's not exactly unheard of... consider annotations, settings, scope membership...
[09:41] <fwereade__> rogpeppe, it is not always neatest or cleanest to stick everything related to X into the document for X
[09:41] <rogpeppe> fwereade__: annotations and settings have a good reason (they can be unbounded in size)
[09:41] <rogpeppe> fwereade__: i don't know about scope membership
[09:41] <fwereade__> rogpeppe, that's mainly about being able to watch sanely
[09:42] <rogpeppe> fwereade__: watch scope membership?
[09:42] <fwereade__> rogpeppe, the real underlying worry is that the more overlapping txns we have on given objects the more contention we'll have
[09:42] <rogpeppe> fwereade__: i worry that we're prematurely optimising here.
[09:42] <fwereade__> rogpeppe, yes; and as a corollary *not* get events on the unit every time something irrelevant happens
[09:43] <rogpeppe> fwereade__: we're making all kinds of guesses about efficiency
[09:43] <rogpeppe> fwereade__: and we don't know anything about the likely distribution of db ops in a large juju environment
[09:43] <fwereade__> rogpeppe, I'm writing the code in the most natural way I see, in accordance with things we've done in the past, and in general a feeling that just slapping everything into one giant object is a poor way to go by default
[09:45] <rogpeppe> fwereade__: putting things into separate collections has costs too though.
[09:45] <fwereade__> rogpeppe, sure; what are the ones that particularly concern you?
[09:46] <rogpeppe> fwereade__: n fetch ops vs 1.
[09:46] <rogpeppe> fwereade__: seeing inconsistent data
[09:47] <fwereade__> rogpeppe, well, the point is to chunk them such that n=1 most of the time, and reap the benefits of sending only the data you need
[09:48] <fwereade__> rogpeppe, and similarly, if related data goes together, you don't see inconsistency there
[09:50] <rogpeppe> fwereade__: perhaps there's is no problem in fact. the issue does concern me though.
[09:52] <fwereade__> rogpeppe, I have tried to plot a sensible course between the two obviously bad extremes -- single-giant-object vs collection-per-attr
[09:54] <fwereade__> rogpeppe, I doubt the course is perfect ofc
[09:55] <rogpeppe> fwereade__: it's probably fine. it's just that every time i turn around there seems to be another collection.
[09:56] <fwereade__> rogpeppe, but as a heuristic I feel that, if there's no overlap between the users of field A and field B, we should at least consider putting them in separate docs
[09:56] <fwereade__> rogpeppe, yeah, I know the feeling, but they're actually pretty useful building blocks
[09:57] <rogpeppe> fwereade__: i feel that there's something to be said for the conceptual integrity of having attributes that relate to an object in the same place.
[09:59] <fwereade__> rogpeppe, IMO wedging unrelated data into a single object is one of the leading causes of decay to conceptual integrity :)
[09:59] <fwereade__> rogpeppe, but I kinda feel we're into aphorism territory here
[09:59] <rogpeppe> fwereade__: yeah
[10:02] <fwereade__> rogpeppe, I think I do understand your concerns; I still think I've made a reasonable choice, but I'm also interested to hear any pain points you encounter because of it, so that I can make better choices in future
[10:02] <fwereade__> rogpeppe, thanks :)
[10:02] <rogpeppe> fwereade__: i will do. np.
[10:21] <frankban> rogpeppe: so, how do we proceed? are you thinking about decoupling the EntityInfo (sent as part of the delta) and the entity docs?
[10:22] <rogpeppe> frankban: yes, that's what i'm going now.
[10:22] <rogpeppe> s/going/doing/
[10:22] <rogpeppe> frankban: i've made the most important change in the code (the decoupling) and am just figuring out the test changes now.
[10:23] <frankban> rogpeppe: cool, thank you
[11:00] <frankban> rogpeppe: in an environment bootstrapped using --upload-tools (quantal) i deployed cs:precise/mysql. the status is stick to pending, in the machine log I see http://pastebin.ubuntu.com/5670077/
[11:00] <rogpeppe> frankban: hmm, that's the issue that dave cheney saw
[11:01] <rogpeppe> frankban: i couldn't reproduce it
[11:02] <frankban> rogpeppe: it seems it only happen when the series of the bootstrap node and the service does not match. I tried to deploy a quantal charm (cs:~charmers/quantal/ceph-3) and I "correctly" have an install error
[11:04] <frankban> rogpeppe: however, I remember I was able to deploy a precise charm using --upload-tools (quantal) last week
[12:21] <rogpeppe> gary_poster: it seems that i can't put off adding that layer of indirection to the allWatcher
[12:21] <rogpeppe> gary_poster: the code is easy, but changing the tests is taking a little while
[12:22] <gary_poster> rogpeppe, is this necessary for the config and constraints, and future state stuff?
[12:22] <rogpeppe> gary_poster: config, constraints, status and probably more stuff too
[12:23] <gary_poster> gotcha
[12:23] <gary_poster> rogpeppe, will this indirection branch add the config and constraints or is it a step along the way
[12:23] <rogpeppe> gary_poster: it's a step along the way
[12:23] <gary_poster> ok (and darn :-) )
[12:24] <rogpeppe> gary_poster: but adding the other stuff should be "easy" (modulo type renaming :-])
[12:24] <gary_poster> heh.  rogpeppe, I suspect we ought to have a call today to see where we are, what more we need, and what the timeline is
[12:25] <rogpeppe> gary_poster: agreed. any time. apart from i've got a call in 35 mins.
[12:26] <gary_poster> cool rogpeppe. I'm hanging out in http://tinyurl.com/guichat and will be ready to talk whenever you are
[12:41] <frankban> gary_poster: do you have time for a quick call?
[12:42] <gary_poster> frankban, sure.  come on by guichat
[12:43] <benji> so much email
[12:50] <rick_h_> benji: bwuhahaha, motivation to never leave
[12:50] <benji> heh
[12:51] <benji> gary_poster: I'm trying to figure out the status of my "Add relationship attributes to watcher" card.  Do you know anything about it?  Did anyone work on it?
[12:52] <gary_poster> benji sent you email.  short answer: no progress, you take it
[12:52] <rick_h_> benji: thought gary_poster sent an email last night. Bottom of your pile :)
[12:52] <rick_h_> doh, too slow
[12:52] <gary_poster> :-)
[12:52] <benji> I read them all so I must have not understood.  
[12:52] <benji> I'll go back and read it again.
[12:54] <gary_poster> benji, look for reply to your status email.  
[12:54] <gary_poster> """I didn't touch this, but I added a card for it (I appropriated the one
[12:54] <gary_poster> you and Francesco were using for my branch).
[12:54] <gary_poster> I also added a card for "add config and constraints to event watcher" to
[12:54] <gary_poster> "Ready to code""""
[12:54] <rick_h_> benji: "Re: More info in deltas" is the subject
[12:54] <gary_poster> biab
[12:54] <rick_h_> <3 notmuch
[12:56] <gary_poster> :-)
[12:57] <gary_poster> frankban, ok ready now :-)
[12:57] <gary_poster> benji, all cool?
[12:58] <benji> gary_poster: yep!  I missed the one line I was looking for.  Reading for comprehension...
[12:58] <gary_poster> :-)
[12:59] <gary_poster> frankban, in guichat again
[13:08] <rogpeppe> gary_poster: i've just realised my regular call has shifted by an hour. let us know when you're done with frankban, and i'll G+ you.
[13:08] <gary_poster> ok thanks rogpeppe
[13:13] <teknico> right! both sides of the pond in sync again, so daily call in 1:15-ish, right?
[13:13] <rick_h_> teknico: rgr
[13:25] <gary_poster> rogpeppe, could you join frankban and me in https://plus.google.com/hangouts/_/7fb7c30f3a232db57dd8549738fb98e723d90d4a ?
[13:56] <hatch> goooooood mornin
[13:56] <hatch> gary_poster: so are you the only one that gets the CI emails now?
[13:58] <bac> hatch: i got a jenkins failure email
[13:58] <hatch> hmm interesting - I only got the one from gary
[13:58] <hatch> maybe it got lost in the internets
[13:58] <hatch> will see if I get the next one
[13:58] <gary_poster> hatch, it was a very big email.  maybe filtered out?
[13:59] <gary_poster> Looks like canonistack is hosed yet again 
[13:59] <gary_poster> Going to kill this one too
[13:59]  * hatch grumbles
[13:59] <gary_poster> no resources is my guess
[13:59] <gary_poster> we are only getting a single machine
[14:00] <hatch> so EC2 would cost us $X/yr could we requisition that $ and buy a box just for us in Canonistack? :D
[14:00] <gary_poster> :-)
[14:00] <hatch> I'm only a little bit joking :)
[14:00] <gary_poster> yeah, I regard building these stats as grist for the mill of getting this fixed one way or another
[14:01] <gary_poster> I'll be able to say "we have had X runs of the CI in one week. Y% failed because of canonistack.  We'd like to fix this or be able to go someplace else."
[14:01] <bac> hatch: if it costs $X to buy a box it'll cost about $100X in time trying to get it purchased and installed.
[14:01] <gary_poster> too true :-(
[14:01] <hatch> bac: isnt' that what juju is for....:P
[14:02] <gary_poster> no, that's what the cloud is for "=/
[14:02] <gary_poster> :-/
[14:02] <hatch> haha
[14:02] <gary_poster> off by one smiley
[14:02] <bac> since benji has such good internet, why don't we just host a box at his house?
[14:03]  * benji considers adding UPS and a raised floor.
[14:03] <gary_poster> hey, that's a great idea! We can all get root on his network!
[14:03] <rick_h_> hah, everyone loves those HP microservers
[14:03] <rick_h_> a shelf full of those should be the awesome!
[14:03] <rick_h_> http://www.jorgecastro.org/2012/04/10/maasing-and-jujuing-with-hp-proliant-micro-servers/
[14:04] <rick_h_> looks like we need to ping robbie for access to robbiestack
[14:05] <rick_h_> luca__: howdy, I just sent an email to alejandra about a possible meet up today. I meant to copy you and sinzui but suffered email fail of the brain. 
[14:07] <bac> late but good: http://youtu.be/9shZslfbaS0
[14:09] <luca__> Hi rick_h_ no problem, I'm available for a catch up but will let Ale reply. We'll be on the standup so we can sort it out then.
[14:13] <benji> that's pretty good
[14:13] <rick_h_> bac: I like the "how many blocks are supposed to be in this iteration?" lol
[14:14] <gary_poster> hey look, the tests are actually runnning now!  how novel
[14:14] <gary_poster> on canonistack I mean
[14:23] <gary_poster> ugh!
[14:24] <gary_poster> and they failed because of bug 1161937.  ugh.
[14:24] <_mup_> Bug #1161937: Unit tests fail in CI initially, intermittently <juju-gui:Triaged> < https://launchpad.net/bugs/1161937 >
[14:24] <hatch> bac: does trunk have our fix from yesterday?
[14:24] <gary_poster> no
[14:24] <bac> no
[14:24] <hatch> oh ok - I was thinking that 'might' fix it?
[14:25] <bac> hatch: i can pull it into a separate branch and land it
[14:25] <hatch> I am almost certain those failures are caused by something along the same lines as we solved yesterday
[14:28] <gary_poster> jujugui, call in 2
[14:31] <gary_poster> frankban, starting without you
[14:32] <frankban> gary_poster: koining
[14:32] <frankban> joining even
[14:44] <benji> bac: that was the best update ever
[14:45] <hatch> lol
[14:47] <luca__> rick_h_: https://plus.google.com/hangouts/_/8dff1ab85e077e6f0c07a33419a091a66c4536d5?authuser=1&hl=en
[15:08] <gary_poster> bcsaller, what's the earliest you would like a regular call time?
[15:11] <bcsaller> gary_poster: even 8am would be an improvement, a 1/2 hr later
[15:12] <gary_poster> that's not the question I asked though ;-) 
[15:13] <gary_poster> bcsaller, ^^
[15:13] <bcsaller> gary_poster: 9am would be my preference but I don't want it to be too late in Europe 
[15:13] <gary_poster> ack.
[15:15] <gary_poster> I could propose M-Th @ 9 and Fri @ 8 bcsaller?
[15:15] <bcsaller> gary_poster: deal :)
[15:15] <gary_poster> cool :-)
[15:17] <gary_poster> hey jujugui.  bcsaller is in a new timezone that means the current daily call time is very early for him.  Does anyone have objections to the following: daily call M-Th, UTC 1600.  weekly call Fri, UTC 1500.
[15:18] <Makyo> gary_poster, Works for me.
[15:18] <gary_poster> thx
[15:18] <benji> that's fine with me
[15:19] <frankban> gary_poster: ok
[15:19] <gary_poster> cool
[15:19] <hatch> iunnoooo
[15:19] <hatch> :P
[15:19] <teknico> gary_poster, fine with me too
[15:19] <gary_poster> thx teknico.  hatch, issue?  let me know if there's a prob
[15:20] <hatch> no no issue :) that's 10am and 9am here so I should be well into working by then
[15:20] <gary_poster> ok cool
[15:21] <hatch> bcsaller: just so we know when we can bug you - what time UTC do you start now?
[15:22] <hatch> rick_h_: is there a way to copy the text from one panel in a split panel window in iterm?
[15:22] <hatch> er tmux in iterm
[15:22] <gary_poster> bac is not here
[15:22] <gary_poster> hoping it is ok with him
[15:23] <hatch> gary_poster: he is on the same timezone as me so I don't think it would be an issue
[15:23] <gary_poster> cool
[15:24] <hatch> gary_poster: to write the remove_units() fakebackend I executed the command on improv and then took note of the req/res and will duplicate that
[15:24] <hatch> ^^ correct approach?
[15:24] <gary_poster> hatch, good start, yes.  For response, you'll want to look at callbacks as well.  Sometimes improv is not as complete
[15:25] <hatch> right gotcha
[15:30] <hatch> rick_h_: I found the answer http://unix.stackexchange.com/questions/58763/copy-text-from-one-tmux-pane-to-another-using-vim
[15:32] <bcsaller> hatch: I think I'm an hour behind you, its 8:30am here now . I usually try to start around now.
[15:32] <hatch> ahh ok cool
[15:32] <hatch> GMT-7 or UTC 15:30
[15:32] <hatch> ;)
[15:33] <hatch> we should schedule everything in UTC time :)
[15:36] <hatch> gary_poster: how did you know to add in all of these if checks in addUnit? Did you also look at improv?
[15:36]  * gary_poster looks
[15:37] <hatch> some of it is similar to service.js but not all of it
[15:42] <hatch> ok nope add_unit.py doesn't have those checks in it either
[15:42] <hatch> looks like you were just being thorough
[15:52]  * hatch just doesn't /get/ yield in python
[15:56] <benji> hatch: to get yield you first have to get generators.  A generator is like a function that instead of returning one thing and stopping can return something and then later be asked for another (and another, etc.)
[15:56] <hatch> so you pass it an array and every time it's called it moves the pointer forward?
[15:57] <benji> "yield" is like "return" except that it means that you can be asked again for another value and you will yield again
[15:57] <benji> nope, "yield" yields whatever you pass it (just like return)
[15:58] <hatch> ok then that's the issue - i don't understand what the difference is...where does this 'next' value come from?
[15:58] <hatch> if your passing new data in... then how is it any different than a function with return
[15:59] <benji> the value passed to yield is what next receives
[16:00] <benji> you don't normally pass in new values to each "iteration" of the generator
[16:00] <benji> normally you pass in values to get it started and then it generates a series of values; every time you call next the generator is run until it yields a value and that is the return value of the next call
[16:01] <hatch> ohh ok ok now I get it
[16:01] <hatch> thanks for that :)
[16:02] <gary_poster> hatch, sorry, I looked, and then was pulled down two rabbit holes.  I climbed back out of one of them, but it looks like you are all taken care of.
[16:03] <hatch> :) no problem
[16:04] <benji> hatch: here is a little generator you could play with: http://paste.ubuntu.com/5670872/
[16:05] <hatch> must....have....curly......braces.....
[16:05] <hatch> :P
[16:05] <benji> :)
[16:06] <benji> It will be no surprise that I feel exactly the opposite. :)
[16:08] <hatch> haha nope - My mind just looks for the closing brackets to compile in my head
[16:08] <hatch> python throws a brain syntax error
[16:08] <hatch> :P
[16:24] <teknico> hatch, then there's "yield from": ;-) http://docs.python.org/3/whatsnew/3.3.html#pep-380-syntax-for-delegating-to-a-subgenerator
[16:25] <rick_h_> luca__: if you get a sec can you pull up the 'weekly' update that last went out and shoot a copy to me/sinzui?
[16:26] <benji> rogpeppe: I am having some test failures that I could use some help on.  I figured several out but one is still getting me: http://paste.ubuntu.com/5670930/
[16:26] <rogpeppe> benji: looking
[16:27] <benji> the problem seems to be that setUpScenario sets up less than what is found, which doesn't make sense to me
[16:27] <rogpeppe> benji: the problem is *probably* that some test op hasn't undone a remove-relation change properly
[16:28] <rogpeppe> benji: i thought some branches relevant to that had already been submitted (though i can't quite remember who was doing them. teknico? frankban?)
[16:28] <benji> hmm, that is a possibility
[16:29] <benji> this branch hasn't merged trunk since Friday, so maybe a merge will magically fix this (after breaking the world with merge conflicts, but I can't have everything)
[16:29] <benji> I'll give that a try and if it doesn't help I'll go on a search and destroy mission for an improperly un-done test.
[16:29] <rogpeppe> benji: y'never know
[16:30] <frankban> rogpeppe: I think teknico did that kind of clean up
[16:30] <rogpeppe> benji: a quick check:
[16:30] <benji> hmm, but the test generates an entirely new scenario, how could another test interfere?
[16:30] <rogpeppe> benji: what does opClientDestroyRelation look like?
[16:30] <benji> func opClientDestroyRelation(c *C, st *api.State, mst *state.State) (func(), error) {
[16:30] <benji> 	err := st.Client().DestroyRelation("nosuch1", "nosuch2")
[16:30] <benji> 	if api.ErrCode(err) == api.CodeNotFound {
[16:31] <benji> 		err = nil
[16:31] <benji> 	}
[16:31] <rogpeppe> benji: ah, i don't know which function your test failure relates to
[16:31] <benji> 	return func() {}, err
[16:31] <benji> }
[16:31] <rogpeppe> benji: perhaps you could push your branch and i'll take a look
[16:31]  * benji notes another point against tabs in source.
[16:31] <rogpeppe> benji: that looks fine
[16:31] <luca__> rick_h_: the last email that me or Jovan has from Nick is from the 1st of March. Do you have that one?
[16:31] <rogpeppe> benji: it's ok, gofmt will put 'em back :-)
[16:32] <teknico> it looks fine to me too
[16:32] <benji> re. tabs: oh, I know
[16:32] <teknico> I added reset() (cleanup) functions to a number of tests
[16:32]  * rogpeppe likes tabs. only one key to indent :-)
[16:33] <benji> teknico: cool, I'm just a little surprised that this function is dependent on global state
[16:33] <rogpeppe> benji: which function is failing?
[16:33] <benji> func (s *allWatcherStateSuite) TestStateBackingGetAll(c *C) {
[16:33]  * teknico likes them too. Used them for months when starting with python eons ago, before being forced to use spaces :-P
[16:34] <rogpeppe> benji: ah, hmm. i'd unwittingly assumed it was api tests failing
[16:35] <benji> I don't think most editors have a problem inserting spaces when you hit the tab key.  Tab key != tab character.
[16:35] <rogpeppe> benji: ah! i see the problem.
[16:35] <benji> yay!
[16:35] <gary_poster> hatch, sorry, I looked, and then was pulled down two rabbit holes.  I climbed back out of one of them, but it looks like you are all taken care of.
[16:35] <rick_h_> luca__: heh ok. So by 'weekly' we've actually not missed a lot? luca__ but no, I don't have an email from nick on march 1.
[16:35] <gary_poster> oh bah
[16:35] <gary_poster> sorry hatch
[16:36] <rogpeppe> benji: you've just added new attributes to RelationInfo, right?
[16:36] <benji> yep
[16:36] <gary_poster> that was supposed to be a different message and my irc client overrode it when I pressed the up key inadvertently
[16:36]  * hatch confused
[16:36] <rogpeppe> benji: so you'll need to change allWatcherStateSuite to add the relevant params to the expected added relation
[16:36] <hatch> oh heh got it
[16:37] <luca__> rick_h_: hmmm do you have one from Nick sent on the 19th?
[16:37] <rogpeppe> allWatcherStateSuite.setUpScenario of course
[16:37] <gary_poster> frankban, when I get an error in the charm like line 12 of http://pastebin.ubuntu.com/5670949/ (ignoring line 13's timeout for the moment) what can I do to diagnose?  The only think I know to do is to try and dupe manually, or rerun with debug-log running.
[16:37] <rogpeppe> benji: ^
[16:37] <benji> I'm confused as to why that should need to be done, but now is probably not the time to relieve that confusion.  Thanks!
[16:38] <rogpeppe> benji: setUpScenario adds stuff to the environment and also returns the stuff we *expect* getAll to fetch.
[16:38] <benji> ah!
[16:39] <benji> but, isn't the thing it returns generated from the things it creates?  or are those two entirely distinct?
[16:39] <rogpeppe> benji: it's hopefully slightly easier to maintain than a large section of code that adds stuff and a large slice with all the stuff that pertains to the code.
[16:40] <arosales> gary_poster: are you targeting have the gui on the tablet running by ODS?
[16:40] <rogpeppe> benji: they're almost entirely distinct
[16:41] <rogpeppe> benji: note that although each change has an equivalent add() call, the add call doesn't interrogate the state.
[16:41] <frankban> gary_poster: it usually prints a traceback. when it doesn't, it probably means jitsu timed out. In general, debug-log helps a lot, and if a single test fails it can be helpful to manually try to do what the failing test does, i.e. deploy the charm with staging=true.
[16:42] <gary_poster> arosales, that's a nice to have
[16:42] <gary_poster> frankban, ack, thank you
[16:42] <gary_poster> arosales, want a quick check-in since I'm out the next three days?
[16:43] <arosales> gary_poster: sure, I have some time this afternoon.  I will look for an open spot
[16:43] <gary_poster> cool
[16:57] <benji> rogpeppe: I have a problem, adding those constants to the expected values will create an import loop
[16:58] <benji> I don't really expect you to do anything about it, just complaining. 
[16:58] <rogpeppe> benji: which constants?
[16:58] <benji> the endpoint data
[17:00] <rogpeppe> benji: that's a bit surprising
[17:00] <rogpeppe> benji: could you paste me the line(s) that cause the loop?
[17:01] <rogpeppe> benji: AFAICS you don't need anything that's not from state/api/params or charm, but i'm probably missing something crucial
[17:02] <benji> rogpeppe: I don't have a loop yet, I just expect one.  Let me go down this road and see if the loop materializes.
[17:26] <frankban> gary_poster: EOD, and I have a prototype/draft of the model handlers/converters. Here is the current diff: http://pastebin.ubuntu.com/5671075/ . If you have time, I'd appreciate some feedback (email) before a continue following this path. Otherwise, no problem. In both cases, have a great week! :-)
[17:26] <gary_poster> thanks frankban, I will look later.  Hope you have a good week too :-)
[17:36] <hatch> gary_poster: do you have a minute for an impromptu review?
[17:36] <gary_poster> hatch, very fast :-)
[17:36] <hatch> http://bazaar.launchpad.net/~hatch/juju-gui/remove-units/revision/483
[17:37] <gary_poster> looking
[17:37] <hatch> thanks :)
[17:37] <rogpeppe> gary_poster: here's the indirection branch: https://codereview.appspot.com/8269043/
[17:38] <rogpeppe> gary_poster: which brings me to eod
[17:38] <rick_h_> hatch: jcsackett Makyo sinzui or anyone else that's feeling in a good mood up for a smallish review please? https://codereview.appspot.com/8268043/
[17:38] <hatch> rick_h_: I'll take one
[17:38] <gary_poster> yay rogpeppe thanks!  have a good evening
[17:38] <rogpeppe> gary_poster: hope you have a good time off!
[17:38] <gary_poster> thank you :-)
[17:38] <rick_h_> thanks hatch 
[17:39] <gary_poster> hatch, fakebackend.js, line 430, why some?  would expect each
[17:39] <gary_poster> use in line 431 makes sense
[17:40] <gary_poster> you never return true in outer loop so some is effectively each
[17:40] <hatch> gary_poster: oh woops, I used to have those two loops inverted so that should be changed to an each
[17:40] <hatch> thanks
[17:40] <hatch> oh wait
[17:40] <gary_poster> cool hatch.  You may want to aggregate errors in line 438
[17:41] <hatch> no that was there on purpose - so that it would stop if it came to an error
[17:41] <hatch> the improv just logs errors to the console then returns false
[17:42] <gary_poster> hatch, then it stops processing?
[17:42] <gary_poster> returns false...
[17:42] <hatch> well it 'raises' so I am assuming?
[17:42] <gary_poster> werid
[17:42] <gary_poster> just like my spelling/typing
[17:42] <hatch> :D
[17:42] <hatch> maybe you could take a look at remove_unit.py just to make sure
[17:42] <gary_poster> k
[17:43] <hatch> it throws exceptions and raises which I'm guessing exits the loop?
[17:44] <gary_poster> hatch
[17:44] <gary_poster>         except ServiceUnitStateNotFound:
[17:44] <gary_poster>             context.log.warning("Unit %r does not exist", unit_name)
[17:44] <gary_poster>             continue
[17:44] <gary_poster> so that means it ignores missing units
[17:45] <hatch> ahh ok I can aggregate the errors then
[17:45] <gary_poster> and then they aren't really errors, oddly enough
[17:45] <gary_poster> just warnings
[17:45] <gary_poster> maybe put as separate attr?
[17:46] <hatch> well err is only checked for truthyness so I will just turn it into an array and push them into there
[17:46] <hatch> as right now it simply returns boolean and logs to the console
[17:46] <gary_poster> hatch but my point is that this is not an error condition
[17:46] <hatch> so this is actually adding more information than we had before
[17:47] <hatch> ohh I see
[17:47] <hatch> I'm not sure what would be an error then
[17:47] <benji> yay, tests pass; my import cycle fears were unfounded
[17:48] <gary_poster> hatch, only error is if unit's service is subordinate: we can't do that
[17:48] <benji> time to see if my merge fears can come true instead
[17:48] <hatch> yeah I didn't even know what that was lol
[17:49] <gary_poster> hatch, I think service has subordinate flag
[17:49] <gary_poster> puppet is subordinate hatch
[17:49] <gary_poster> because it runs on the same machine as a, uh, non-subordinate charm, and supports
[17:49] <gary_poster> you could have a logging charm too
[17:49] <gary_poster> it is something that is supposed to be able to support ither charms
[17:49] <hatch> oh ok - so is that something I should be taking into account?
[17:49] <gary_poster> other
[17:50] <gary_poster> nagios is another example
[17:50] <gary_poster> hatch, would be easy to: get the service and loog at the subordinate flag
[17:50] <gary_poster> look
[17:50] <hatch> alright I'll be sure to add that
[17:51] <gary_poster> hatch your logic in performOp_remove_units looks a bit weird in lines 385-386
[17:51] <gary_poster> if (!res) then res.error would exist
[17:51] <hatch> it's because res is boolean
[17:52] <gary_poster> hatch, but an error object will also be truthy
[17:52] <gary_poster> I'd document the return values of removeUnits also in the pydoc thing
[17:52] <hatch> yeah so if (res.error) { data.err = res.error; } data.result = res;
[17:53] <gary_poster> hatch that would work if you changed the output of removeUnits, yes
[17:53] <gary_poster> hatch, think about what a reasonable reply from removeUnits would be in the abstract
[17:53] <hatch> yeah I think I'll try and mirror the other methods
[17:53] <hatch> to make it consistent
[17:54] <gary_poster> for instance, I'd be tempted to return a hash of {removed: [], notFound: []} *or* {error: ...}
[17:54] <gary_poster> but that's off the cuff
[17:55] <hatch> yeah I could do that if that's allowed
[17:55] <hatch> you said yesterday not to return any extra data than what's already there
[17:55] <hatch> so I was trying to stick to that :D
[17:56] <gary_poster> hatch, remember, there's a difference between fakebackend and pyjujuapi
[17:56] <hatch> oh right, fakebackend can return whatever
[17:56] <hatch> pyjujuapi only return the same stuff
[17:56] <gary_poster> fakebackend is just supposed to be helpful JS thing with helpful JS API including helpful JS responses
[17:56] <gary_poster> right
[17:57] <hatch> ok so check for subordinate and aggregate warnings
[17:57] <hatch> fix conditional
[17:58] <gary_poster> I assume you will use your new generateServices helper to refactor the add unit test from yesterday too
[17:58] <gary_poster> good idea
[17:59] <hatch> yep I will for sure
[17:59] <gary_poster> good work hatch, on the right track
[18:00] <hatch> thanks
[18:00]  * gary_poster returns to reviews
[18:00] <hatch> getting the hang of this system heh
[18:13] <benji> gary_poster: I am going to take the rest of lunch now (I was trying to get my branch done before the juju-core guys disappeared, almost made it) but I could use your advice about what to do afterward
[18:13] <gary_poster> cool benji.
[18:15] <gary_poster> benji, would be great if you could review the py env and go env commands and note any missing pieces.  We only have set-config listed on board now
[18:15] <gary_poster> with get-config and get_endpoints in progress
[18:15] <benji> gary_poster: ok, I'll take a look
[18:15] <gary_poster> if there are any others we should make cards, and then tackle
[18:15] <gary_poster> thank you
[18:16] <hatch> rick_h_: review done
[18:19] <rick_h_> hatch: thanks!
[18:29] <rick_h_> hatch: replies sent. Thanks for the catches
[18:29] <rick_h_> and suggestion on lazy loading the attr
[18:30] <hatch> rick_h_: got it thanks
[18:30] <hatch> so...
[18:31] <rick_h_> hatch: so api is giving me: http://staging.jujucharms.com/api/0/charm/precise/cassandra-1
[18:31] <rick_h_> hatch: see the options
[18:31] <rick_h_> I need to loop/output those for display through handlebars which doesn't look looping over objects, but wants arrays
[18:32] <hatch> yep I understand that
[18:32] <rick_h_> k
[18:32] <hatch> I don't think that config should be there at all
[18:32] <hatch> I'd probably move that getter into a fn
[18:32] <hatch> which would pull the data from the object and format it
[18:32] <hatch> as I don't think that an attribute should be used as only a getter for another attribute
[18:33] <rick_h_> hatch: well, I want this to be backwards compatible with the old charm model and I'll be passing this to the environment/config editing code from you guys
[18:33] <rick_h_> hatch: so I want to keep split things I just need for me vs changing the model api as a whole. 
[18:33] <rick_h_> hatch: though I could just move this to the view, but then I can't render the templates as model.getAttrs() :)
[18:33] <rick_h_> hatch: so maybe if you don't want the double in the model I should look at moving the logic to the view instead
[18:34] <hatch> if you set the model on the view to be this model then you could
[18:35] <rick_h_> hatch: not following that last statement
[18:35] <hatch> well if you're in your view and you set the views model to be this model then you would go template(this.get('model').getAttrs());
[18:36] <hatch> assuming template is a hbs render function
[18:36] <rick_h_> hatch: right, so it's called 'charm' and I do that currently. template(this.get('charm').getAttrs())
[18:36] <rick_h_> but you're saying you don't like both options and config being in the model correct?
[18:37] <hatch> no no, what I mean is that I don't like an attribute being created just to format another attribute
[18:37] <hatch> to me you should be creating a parse getter method
[18:37] <hatch> getFormattedObject: function() {}
[18:37] <rick_h_> hatch: right, but I want to keep the original object based attribute. I don't want to replace it
[18:38] <hatch> that's fine - it would be accessible via this.get('object')
[18:38] <rick_h_> hatch: but you're right, what might be better is to add it as a method on the charm. charm.getOptionsAsArray
[18:38] <hatch> and getFormattedObject would return the formatted object
[18:38] <hatch> yeah - that's what I mean
[18:38] <hatch> I ran into a similar situation in a previous project
[18:39] <rick_h_> ah ok gotcha. I thought you wanted to change the parse method on the model for load/etc which isn't what I wanted
[18:39] <hatch> oh no no definitely not :)
[18:39] <hatch> so do you agree with the approach I'm suggesting?
[18:40] <rick_h_> hatch: I *think* so. I'll update here in a sec
[18:40] <hatch> alright :)
[18:40] <rick_h_> can you call methods from handlebars? I didn't think so. 
[18:40] <rick_h_> so I can't do {{#each this.getOptionsAsArray()}} right?
[18:41] <rick_h_> yea, nvm
[18:42] <hatch> only via a helper
[18:57]  * hatch lunching &
[19:03] <rick_h_> hatch: updated when you get time https://codereview.appspot.com/8268043/ 
[19:03] <rick_h_> jcsackett: have time to look as well please? ^^
[19:04] <jcsackett> rick_h_: looking.
[19:08] <Makyo> Turns out, these are not valid x/y coordinates: http://pastebin.ubuntu.com/5671410/
[19:12] <hatch> Makyo: rofl
[19:13] <hatch> it is actually on the cardashian plain lol
[19:13] <gary_poster> Makyo, lol
[19:14] <Makyo> Just a little side effect of storing annotations as map[string]string.
[19:16] <hatch> rick_h_: LGTM'd
[19:16] <rick_h_> hatch: thanks
[19:17] <gary_poster> bac, I don't have time for a review, but your endpointsbranch looks darn impressive on the face of it
[19:18] <bac> gary_poster: thx.  hopefully i'll get it landed today.
[19:18] <bac> lots of red in the branch.  :)
[19:18] <benji> unhelpful test failur of the day goes to:
[19:18] <benji> ... obtained params.Delta = params.Delta{Removed:false, Entity:(*params.RelationInfo)(0xf8400e7420)}
[19:18] <benji> ... expected params.Delta = params.Delta{Removed:false, Entity:(*params.RelationInfo)(0xf8400c8d20)}
[19:19] <hatch> bac: reviewing
[19:19] <bac> benji: ah, those objects don't match.  you should make them be the same.
[19:19] <benji> heh
[19:20] <bac> hatch: not just yet.  i don't think the final version is on Rietveld yet
[19:20] <bac> i did a -wip first
[19:20] <hatch> oh alright
[19:20] <hatch> lemme know
[19:20] <bac> lbox propose is crazy slow
[19:21] <hatch> I'm getting quotes to reroof/shingle my garage roof today
[19:21]  * hatch don't feel so good no mo
[19:21] <bac> my roof is 18 years old.  /me keeps his fingers crossed
[19:21] <hatch> ~$3500 to sheet and shingle a detached garage...
[19:21] <hatch> that's like $2000 labour haha
[19:22] <bac> hatch: now it is up: https://codereview.appspot.com/8275043
[19:22] <hatch> cool
[19:27] <hatch> bac: does this need to be QA'd?
[19:27] <bac> hatch: er?
[19:27] <hatch> like a manual QA
[19:27] <hatch> make sure everything still works as expected
[19:27] <bac> hatch: are you asking if i've run it locally?  yes.
[19:28] <bac> hatch: more poking at it would be appreciated
[19:33] <hatch> bac: why are you binding to null in endpoints.js ln 167? I remember you saying the reasoning but now I can't remember
[19:33] <hatch> :)
[19:35] <bac> hatch: as before, b/c i don't care about the context but just need to curry in other params
[19:35] <hatch> ahh yes
[19:35] <bac> hatch: i see i left some commented code a few lines above.  please mark those so i don't forget to remove them
[19:36] <bac> nm, i just killed them
[19:37] <hatch> yeah I already marked em
[19:38] <hatch> so...
[19:38] <hatch> I'm a little concerned that these utility methods are just hanging off of juju.models
[19:38] <hatch> imho they should be in a closure in juju.models.utils or something
[19:38] <hatch> thoughts?
[19:39] <bac> no thoughts, open to suggestions.  they do look a little bare.
[19:39] <hatch> alright well if you're not opposed to it then I'll make a note and come back to it
[19:40] <hatch> lol if(true) wth lint
[19:57] <hatch> bac: review completed - I'd like to get some others input on moving the code into it's own closure
[19:58] <bac> hatch: thanks.
[19:58] <hatch> that's the only reason why it wasn't LGTM'd just fyi
[20:00] <bac> hatch: the linter was complaining about the body of a for (x in...)  loop needing to be enclosed in an if
[20:00] <hatch> that's crazy I've never heard of that before
[20:01] <hatch> thenagain me and that linter don't agree on a lot of fronts :D
[20:01] <bac> i think it is to force you to use a hasOwnProperty test?  didn't seem appropriate here
[20:01] <hatch> ahh I suppose that's valid
[20:01] <bac> the if (true) was used elsewhere so i stole it
[20:01] <hatch> I guess you could also switch to a YUI iterator of sorts
[20:02] <rick_h_> I broke jenkins. Does anyone have access to give it a boot? gary_poster ran it again earlier with success on my first branch today.
[20:04] <gary_poster> rick_h_, on it
[20:04] <rick_h_> gary_poster: ty much
[20:04] <hatch> rick_h_ yep
[20:04] <hatch> oh
[20:04] <rick_h_> sorry to keep bringing it down :(
[20:04] <hatch> nm :)
[20:04] <gary_poster> rick_h_, not your fault :-(
[20:04]  * rick_h_ wonders why jenkins hates him so...goes to buy flowers
[20:04] <hatch> gary_poster: do I have your blessing this week to look into cleaning up the tests for an afternoon to try and solve that issue?
[20:05] <hatch> :)
[20:05] <gary_poster> on call
[20:06] <hatch> anyone else need any reviews before I get back to doing real work? ;)
[20:22] <benji> Makyo: I'm reviewing your branch.
[20:23] <Makyo> benji, \o/
[20:23] <Makyo> I'll back out the config-debug changes, forgot to revert that.
[20:24] <hatch> is there a way to get a service model from a unit name?
[20:24] <hatch> or do I need to split on '/' ?
[20:32] <gary_poster> hatch, re blessing: if the in-browser stuff is nearing completion--only a few "implement X" cards left--or if you are blocked, yes
[20:32] <hatch> alright I'll keep that in my back pocket
[20:32] <gary_poster> cool
[20:32]  * gary_poster goes to  reviews
[20:34] <gary_poster> bac, hatch, very open to hatch's idea of a separate closure.  I'd like that to be a separate, follow-on branch if that's what you decide to do
[20:34] <bac> ok
[20:35] <gary_poster> unless it is done already, of course.  my point is merely that if this works, it unblocks other efforts, and is a great incremental step forward, so let's land it
[20:39] <bac> Makyo: two reviews done on your branch
[20:40] <bac> gary_poster: hatch's suggestion has not been done yet
[20:42] <bac> bcsaller: great suggestions.  thanks.
[20:42] <bcsaller> bac: :) glad to help
[20:47] <bac> gary_poster: could you please review ben's comments and leave a comment on the MP as how you'd like me to proceed?
[20:47] <gary_poster> ok
[20:47] <gary_poster> bac, how long will it take
[20:49] <bac> probably 1/2 day
[20:52] <gary_poster> bac, not too bad.  up to you but I suggest that you see if you can identify a compromise with reviewers to land this today (or early tomorrow) and then make a new branch tomorrow.  ben's db stuff in particular is the right thing to do technically, though not necessary at this instance, bot if it is half a day and you land incrementally I'm ok with it
[20:52] <gary_poster> but
[20:54] <bac> bcsaller, hatch: you ok with that?  land the branch basically as is with a follow on fix?
[20:55] <hatch> yeah sure - I'll LGTM it if you can be sure you destroy that stuff in the test please :)
[21:00] <bcsaller> bac: I'm ok with that plan as well, if another card is made. 
[21:00] <bcsaller> I'll update the MP
[21:00] <bcsaller> or CR, whatever :)
[21:00] <bac> thanks
[21:10] <bac> hatch: your comment about cleaning up in the tests is directed at the creation of a charm.  but the charm doesn't have any attached events as your comments states.  so to be clear, you are requesting the service with the events be destroyed or the charm too?
[21:10] <bac> hatch: it's not enough to destroy the env and app?
[21:11] <hatch> bac: I may have misread - but I thought it was attaching events to something that wasn't being destroyed
[21:11] <hatch> if that's not the case then feel free to disregard
[21:12] <hatch> let me check
[21:12] <bac> hatch: the events are attached to the services modellist.
[21:12] <bac> lord knows i don't want to introduce any extra test time bombs
[21:16] <hatch> bac: ok looks like the instance I was concerned about is actually attaching an event to itself so if you charm.destroy(); every time you `new models.Charm();` then that will be good
[21:17] <hatch> I figure that anytime we use `new` we should follow it up with a `destroy()`
[21:17] <hatch> I'm hoping that will help :D
[21:30] <hatch> gary_poster: any idea how I can test the is_subordinate code?
[21:30] <hatch> since we dont' have a connection to the real charm store
[21:30] <gary_poster> hatch not sure what you mean--sorry a lot of plates going.  context?
[21:31] <hatch> the remove_unit fake back end code now throws errors if the service is_subordinate
[21:31] <hatch> to match the improv code
[21:31] <hatch> but how do I create a subordinate service
[21:37] <hatch> I guess I could create another dataset in test/data with a subordinate charm?
[21:37] <gary_poster> hatch just flip the flag on the service?
[21:37] <gary_poster> in a test setup?
[21:37] <hatch> oh heh...I never thought of that
[21:37]  * hatch slowly walks away
[21:38] <gary_poster> :-)
[21:58] <Makyo> benji, I know it's late, but are you still around?
[21:58] <benji> Makyo: just barely
[21:59] <Makyo> benji, quick question, feel free to tell me off.  Which yuidoc comment style do you prefer?  I used one from the yuidoc docs, but can easily change.
[22:00] <benji> I don't really care, we started with the ones with *s down the side then some started removing the stars and one of the spaces (leaving the text 2-space indented from the opening "/**"
[22:00] <benji> yours have /**, no indent and then **/  (as opposed to "*/") plus I'm sure there is one or two other variations
[22:01] <hatch> In need of 2x reviews please https://codereview.appspot.com/8280044/
[22:01] <benji> so my comment was more of a "we need to figure out what we want and enforce it" than a "you're doing it wrong! die in a fire!" ;)
[22:01] <Makyo> benji, alright.  Deindented while trying to remove the star, will hunt around for the most consistent.  And yeah, no fires :)
[22:01] <hatch> I do /** */ then with a 2space indent
[22:02] <hatch> with no stars down the side
[22:02] <Makyo> Alright.
[22:02] <benji> ^^^ would be a fine prescription as far as I am concerned 
[22:02] <hatch> Makyo: you can see how I do it while you're reviewing my branch :P
[22:02] <hatch> haha
[22:02] <benji> (and I'll even try to get around to updating the yuidoc linter to complain on anything else)
[22:03] <Makyo> Well played.  I'll review it just for that :)
[22:03] <hatch> lol ^5
[22:15] <hatch> jujugui anyone else available for a review before EOD?
[22:15] <benji> hatch: I can get you real quick.
[22:15] <benji> https://codereview.appspot.com/8280044/ right?
[22:15] <hatch> great thanks
[22:15] <hatch> yep
[22:22] <benji> hatch: done
[22:23] <gary_poster> hatch I will look before I stop today
[22:23] <hatch> gary_poster: no need, both done :)
[22:23] <hatch> thanks though
[22:23] <gary_poster> but if you have other reviews and feel good about it land
[22:23] <gary_poster> cool
[22:27] <hatch> now onto expose and unexpose
[22:28] <hatch> oh no first I'll clean up those tests with my new utility methods
[22:44] <hatch> hey look at that, CI test caught a real failure
[22:44] <hatch> lol
[22:45]  * hatch is fixing
[22:54] <hatch> hmm unable to reproduce failure on my local machine
[22:54] <hatch> will fire off another CI see if it was a fluke
[22:56] <hatch> hmm the test happens on prod on IE
[22:56] <hatch> investigating
[23:00] <hatch> *sigh*
[23:02] <hatch> looks like a bad merge into trunk
[23:02] <hatch> OR not
[23:08] <hatch> I love when different tests fail every time you run them
[23:17] <hatch> hmm it's failing on revno 487
[23:17] <hatch> going to keep stepping back
[23:26] <hatch> anyone else around still with a win 8 vm?
[23:33] <hatch> ok somewhere between 483 and 486 breaks IE
[23:33] <hatch> sorry its taking me a while to build each version....slow internets
[23:43] <hatch> ok some change http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/revision/486 causes tests to fail in IE all over the place
[23:49] <hatch> ok it's in test_charm_container.js
[23:54] <hatch> test 'only shows items up to the cutoff at first' causes it to fail...
[23:56] <hatch> oh rofl wow - I can't believe it
[23:56] <hatch> ok I'll patch this tonight
[23:57] <rick_h_> hatch: we brokage things on you? 
[23:58] <rick_h_> hatch: heh, yea we talked about getting a Windows/IE10 setup going for everyone today actually. That sucks
[23:58] <hatch> rick_h_: well....yes you 'did' but it's not your's or jc's fault
[23:59] <hatch> the changes to CharmContainer somehow exposed an issue that we were destroying the container and THEN destroying the CharmContainer instance causing it to throw errors when it tried to destroy the container