[00:00] can do! [00:00] hatch, after that, expose and unexpose would be easy things to do, I bet. [00:00] alright assigned [00:01] 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] but that should also follow existing patterns [00:03] sounds good [09:15] 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] frankban: i see that too. it should be fixed. [09:15] frankban: nothing depends in builddb though, i don't think, so it's not critical [09:17] rogpeppe: doesn't it prevent juju-core to be "go install"ed? [09:17] frankban: no. just builddb [09:18] rogpeppe: ok [09:20] 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] 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] frankban: it's a bit weird that constraints are in their own collection [09:21] fwereade__: why are constraints in their own collection? [09:21] rogpeppe: because constraints are only related to units? [09:24] frankban: no, constraints are related to units, services and machines [09:25] frankban: the difficulty is that neither constraintsDoc nor settingsDoc hold the entity name in the doc [09:26] frankban: well, actually there's no settingsDoc per sre [09:26] s/sre/se/ [09:26] rogpeppe: yes, the tag [09:29] rogpeppe: AFAICT constraints include the global key (pk) and settings something else (e.g. serviceSettingsKey) [09:30] frankban: yes - i think the service settings key is to allow charm upgrades [09:30] frankban: but i don't know much of the detail [09:31] rogpeppe: so we need a way to include the entity tag in both docs [09:32] 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] rogpeppe: cool, thanks [09:33] rogpeppe, frankban, hey, sorry [09:33] morning fwereade__ [09:34] 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] rogpeppe, frankban: consider also settings [09:35] fwereade__: aren't they attributes of the entities in question? [09:35] rogpeppe, I'm not sure there's anything strongly indicating that they must be [09:35] fwereade__: it seems a bit weird that you can do Service.Watch but you don't see the service constraints change [09:36] fwereade__: well, we could have every attribute in its own collection [09:36] fwereade__: i'm not sure that would be good though [09:36] rogpeppe, well, I'm not proposing that... [09:37] fwereade__: i'm not sure what you think is good about having attributes of an object spread across separate collections. [09:40] rogpeppe, well, it's not exactly unheard of... consider annotations, settings, scope membership... [09:41] rogpeppe, it is not always neatest or cleanest to stick everything related to X into the document for X [09:41] fwereade__: annotations and settings have a good reason (they can be unbounded in size) [09:41] fwereade__: i don't know about scope membership [09:41] rogpeppe, that's mainly about being able to watch sanely [09:42] fwereade__: watch scope membership? [09:42] rogpeppe, the real underlying worry is that the more overlapping txns we have on given objects the more contention we'll have [09:42] fwereade__: i worry that we're prematurely optimising here. [09:42] rogpeppe, yes; and as a corollary *not* get events on the unit every time something irrelevant happens [09:43] fwereade__: we're making all kinds of guesses about efficiency [09:43] fwereade__: and we don't know anything about the likely distribution of db ops in a large juju environment [09:43] 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] fwereade__: putting things into separate collections has costs too though. [09:45] rogpeppe, sure; what are the ones that particularly concern you? [09:46] fwereade__: n fetch ops vs 1. [09:46] fwereade__: seeing inconsistent data [09:47] 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] rogpeppe, and similarly, if related data goes together, you don't see inconsistency there [09:50] fwereade__: perhaps there's is no problem in fact. the issue does concern me though. [09:52] rogpeppe, I have tried to plot a sensible course between the two obviously bad extremes -- single-giant-object vs collection-per-attr [09:54] rogpeppe, I doubt the course is perfect ofc [09:55] fwereade__: it's probably fine. it's just that every time i turn around there seems to be another collection. [09:56] 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] rogpeppe, yeah, I know the feeling, but they're actually pretty useful building blocks [09:57] 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] rogpeppe, IMO wedging unrelated data into a single object is one of the leading causes of decay to conceptual integrity :) [09:59] rogpeppe, but I kinda feel we're into aphorism territory here [09:59] fwereade__: yeah [10:02] 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] rogpeppe, thanks :) [10:02] fwereade__: i will do. np. [10:21] 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] frankban: yes, that's what i'm going now. [10:22] s/going/doing/ [10:22] frankban: i've made the most important change in the code (the decoupling) and am just figuring out the test changes now. [10:23] rogpeppe: cool, thank you [11:00] 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] frankban: hmm, that's the issue that dave cheney saw [11:01] frankban: i couldn't reproduce it [11:02] 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] rogpeppe: however, I remember I was able to deploy a precise charm using --upload-tools (quantal) last week [12:21] gary_poster: it seems that i can't put off adding that layer of indirection to the allWatcher [12:21] gary_poster: the code is easy, but changing the tests is taking a little while [12:22] rogpeppe, is this necessary for the config and constraints, and future state stuff? [12:22] gary_poster: config, constraints, status and probably more stuff too [12:23] gotcha [12:23] rogpeppe, will this indirection branch add the config and constraints or is it a step along the way [12:23] gary_poster: it's a step along the way [12:23] ok (and darn :-) ) [12:24] gary_poster: but adding the other stuff should be "easy" (modulo type renaming :-]) [12:24] 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] gary_poster: agreed. any time. apart from i've got a call in 35 mins. [12:26] cool rogpeppe. I'm hanging out in http://tinyurl.com/guichat and will be ready to talk whenever you are [12:41] gary_poster: do you have time for a quick call? [12:42] frankban, sure. come on by guichat [12:43] so much email [12:50] benji: bwuhahaha, motivation to never leave [12:50] heh [12:51] 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] benji sent you email. short answer: no progress, you take it [12:52] benji: thought gary_poster sent an email last night. Bottom of your pile :) [12:52] doh, too slow [12:52] :-) [12:52] I read them all so I must have not understood. [12:52] I'll go back and read it again. [12:54] benji, look for reply to your status email. [12:54] """I didn't touch this, but I added a card for it (I appropriated the one [12:54] you and Francesco were using for my branch). [12:54] I also added a card for "add config and constraints to event watcher" to [12:54] "Ready to code"""" [12:54] benji: "Re: More info in deltas" is the subject [12:54] biab [12:54] <3 notmuch [12:56] :-) [12:57] frankban, ok ready now :-) [12:57] benji, all cool? [12:58] gary_poster: yep! I missed the one line I was looking for. Reading for comprehension... [12:58] :-) [12:59] frankban, in guichat again [13:08] 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] ok thanks rogpeppe [13:13] right! both sides of the pond in sync again, so daily call in 1:15-ish, right? [13:13] teknico: rgr [13:25] rogpeppe, could you join frankban and me in https://plus.google.com/hangouts/_/7fb7c30f3a232db57dd8549738fb98e723d90d4a ? [13:56] goooooood mornin [13:56] gary_poster: so are you the only one that gets the CI emails now? [13:58] hatch: i got a jenkins failure email [13:58] hmm interesting - I only got the one from gary [13:58] maybe it got lost in the internets [13:58] will see if I get the next one [13:58] hatch, it was a very big email. maybe filtered out? [13:59] Looks like canonistack is hosed yet again [13:59] Going to kill this one too [13:59] * hatch grumbles [13:59] no resources is my guess [13:59] we are only getting a single machine [14:00] so EC2 would cost us $X/yr could we requisition that $ and buy a box just for us in Canonistack? :D [14:00] :-) [14:00] I'm only a little bit joking :) [14:00] yeah, I regard building these stats as grist for the mill of getting this fixed one way or another [14:01] 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] 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] too true :-( [14:01] bac: isnt' that what juju is for....:P [14:02] no, that's what the cloud is for "=/ [14:02] :-/ [14:02] haha [14:02] off by one smiley [14:02] 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] hey, that's a great idea! We can all get root on his network! [14:03] hah, everyone loves those HP microservers [14:03] a shelf full of those should be the awesome! [14:03] http://www.jorgecastro.org/2012/04/10/maasing-and-jujuing-with-hp-proliant-micro-servers/ [14:04] looks like we need to ping robbie for access to robbiestack [14:05] 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] late but good: http://youtu.be/9shZslfbaS0 [14:09] 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] that's pretty good [14:13] bac: I like the "how many blocks are supposed to be in this iteration?" lol [14:14] hey look, the tests are actually runnning now! how novel [14:14] on canonistack I mean [14:23] ugh! [14:24] and they failed because of bug 1161937. ugh. [14:24] <_mup_> Bug #1161937: Unit tests fail in CI initially, intermittently < https://launchpad.net/bugs/1161937 > [14:24] bac: does trunk have our fix from yesterday? [14:24] no [14:24] no [14:24] oh ok - I was thinking that 'might' fix it? [14:25] hatch: i can pull it into a separate branch and land it [14:25] I am almost certain those failures are caused by something along the same lines as we solved yesterday [14:28] jujugui, call in 2 [14:31] frankban, starting without you [14:32] gary_poster: koining [14:32] joining even [14:44] bac: that was the best update ever [14:45] lol [14:47] rick_h_: https://plus.google.com/hangouts/_/8dff1ab85e077e6f0c07a33419a091a66c4536d5?authuser=1&hl=en [15:08] bcsaller, what's the earliest you would like a regular call time? [15:11] gary_poster: even 8am would be an improvement, a 1/2 hr later [15:12] that's not the question I asked though ;-) [15:13] bcsaller, ^^ [15:13] gary_poster: 9am would be my preference but I don't want it to be too late in Europe [15:13] ack. [15:15] I could propose M-Th @ 9 and Fri @ 8 bcsaller? [15:15] gary_poster: deal :) [15:15] cool :-) [15:17] 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] gary_poster, Works for me. [15:18] thx [15:18] that's fine with me [15:19] gary_poster: ok [15:19] cool [15:19] iunnoooo [15:19] :P [15:19] gary_poster, fine with me too [15:19] thx teknico. hatch, issue? let me know if there's a prob [15:20] no no issue :) that's 10am and 9am here so I should be well into working by then [15:20] ok cool [15:21] bcsaller: just so we know when we can bug you - what time UTC do you start now? [15:22] rick_h_: is there a way to copy the text from one panel in a split panel window in iterm? [15:22] er tmux in iterm [15:22] bac is not here [15:22] hoping it is ok with him [15:23] gary_poster: he is on the same timezone as me so I don't think it would be an issue [15:23] cool [15:24] 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] ^^ correct approach? [15:24] hatch, good start, yes. For response, you'll want to look at callbacks as well. Sometimes improv is not as complete [15:25] right gotcha [15:30] rick_h_: I found the answer http://unix.stackexchange.com/questions/58763/copy-text-from-one-tmux-pane-to-another-using-vim [15:32] hatch: I think I'm an hour behind you, its 8:30am here now . I usually try to start around now. [15:32] ahh ok cool [15:32] GMT-7 or UTC 15:30 [15:32] ;) [15:33] we should schedule everything in UTC time :) [15:36] 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] some of it is similar to service.js but not all of it [15:42] ok nope add_unit.py doesn't have those checks in it either [15:42] looks like you were just being thorough [15:52] * hatch just doesn't /get/ yield in python [15:56] 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] so you pass it an array and every time it's called it moves the pointer forward? [15:57] "yield" is like "return" except that it means that you can be asked again for another value and you will yield again [15:57] nope, "yield" yields whatever you pass it (just like return) [15:58] ok then that's the issue - i don't understand what the difference is...where does this 'next' value come from? [15:58] if your passing new data in... then how is it any different than a function with return [15:59] the value passed to yield is what next receives [16:00] you don't normally pass in new values to each "iteration" of the generator [16:00] 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] ohh ok ok now I get it [16:01] thanks for that :) [16:02] 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] :) no problem [16:04] hatch: here is a little generator you could play with: http://paste.ubuntu.com/5670872/ [16:05] must....have....curly......braces..... [16:05] :P [16:05] :) [16:06] It will be no surprise that I feel exactly the opposite. :) [16:08] haha nope - My mind just looks for the closing brackets to compile in my head [16:08] python throws a brain syntax error [16:08] :P === matsubara is now known as matsubara-lunch [16:24] 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] 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] 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] benji: looking [16:27] the problem seems to be that setUpScenario sets up less than what is found, which doesn't make sense to me [16:27] benji: the problem is *probably* that some test op hasn't undone a remove-relation change properly [16:28] 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] hmm, that is a possibility [16:29] 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] 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] benji: y'never know [16:30] rogpeppe: I think teknico did that kind of clean up [16:30] benji: a quick check: [16:30] hmm, but the test generates an entirely new scenario, how could another test interfere? [16:30] benji: what does opClientDestroyRelation look like? [16:30] func opClientDestroyRelation(c *C, st *api.State, mst *state.State) (func(), error) { [16:30] err := st.Client().DestroyRelation("nosuch1", "nosuch2") [16:30] if api.ErrCode(err) == api.CodeNotFound { [16:31] err = nil [16:31] } [16:31] benji: ah, i don't know which function your test failure relates to [16:31] return func() {}, err [16:31] } [16:31] 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] benji: that looks fine [16:31] 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] benji: it's ok, gofmt will put 'em back :-) [16:32] it looks fine to me too [16:32] re. tabs: oh, I know [16:32] I added reset() (cleanup) functions to a number of tests [16:32] * rogpeppe likes tabs. only one key to indent :-) [16:33] teknico: cool, I'm just a little surprised that this function is dependent on global state [16:33] benji: which function is failing? [16:33] 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] benji: ah, hmm. i'd unwittingly assumed it was api tests failing [16:35] I don't think most editors have a problem inserting spaces when you hit the tab key. Tab key != tab character. [16:35] benji: ah! i see the problem. [16:35] yay! [16:35] 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] 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] oh bah [16:35] sorry hatch [16:36] benji: you've just added new attributes to RelationInfo, right? [16:36] yep [16:36] 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] benji: so you'll need to change allWatcherStateSuite to add the relevant params to the expected added relation [16:36] oh heh got it [16:37] rick_h_: hmmm do you have one from Nick sent on the 19th? [16:37] allWatcherStateSuite.setUpScenario of course [16:37] 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] benji: ^ [16:37] 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] benji: setUpScenario adds stuff to the environment and also returns the stuff we *expect* getAll to fetch. [16:38] ah! [16:39] but, isn't the thing it returns generated from the things it creates? or are those two entirely distinct? [16:39] 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] gary_poster: are you targeting have the gui on the tablet running by ODS? [16:40] benji: they're almost entirely distinct [16:41] benji: note that although each change has an equivalent add() call, the add call doesn't interrogate the state. [16:41] 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] arosales, that's a nice to have [16:42] frankban, ack, thank you [16:42] arosales, want a quick check-in since I'm out the next three days? [16:43] gary_poster: sure, I have some time this afternoon. I will look for an open spot [16:43] cool === matsubara-lunch is now known as matsubara [16:57] rogpeppe: I have a problem, adding those constants to the expected values will create an import loop [16:58] I don't really expect you to do anything about it, just complaining. [16:58] benji: which constants? [16:58] the endpoint data [17:00] benji: that's a bit surprising [17:00] benji: could you paste me the line(s) that cause the loop? [17:01] 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] 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] 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! :-) === deryck is now known as deryck[lunch] [17:26] thanks frankban, I will look later. Hope you have a good week too :-) [17:36] gary_poster: do you have a minute for an impromptu review? [17:36] hatch, very fast :-) [17:36] http://bazaar.launchpad.net/~hatch/juju-gui/remove-units/revision/483 [17:37] looking [17:37] thanks :) [17:37] gary_poster: here's the indirection branch: https://codereview.appspot.com/8269043/ [17:38] gary_poster: which brings me to eod [17:38] 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] rick_h_: I'll take one [17:38] yay rogpeppe thanks! have a good evening [17:38] gary_poster: hope you have a good time off! [17:38] thank you :-) [17:38] thanks hatch [17:39] hatch, fakebackend.js, line 430, why some? would expect each [17:39] use in line 431 makes sense [17:40] you never return true in outer loop so some is effectively each [17:40] gary_poster: oh woops, I used to have those two loops inverted so that should be changed to an each [17:40] thanks [17:40] oh wait [17:40] cool hatch. You may want to aggregate errors in line 438 [17:41] no that was there on purpose - so that it would stop if it came to an error [17:41] the improv just logs errors to the console then returns false [17:42] hatch, then it stops processing? [17:42] returns false... [17:42] well it 'raises' so I am assuming? [17:42] werid [17:42] just like my spelling/typing [17:42] :D [17:42] maybe you could take a look at remove_unit.py just to make sure [17:42] k [17:43] it throws exceptions and raises which I'm guessing exits the loop? [17:44] hatch [17:44] except ServiceUnitStateNotFound: [17:44] context.log.warning("Unit %r does not exist", unit_name) [17:44] continue [17:44] so that means it ignores missing units [17:45] ahh ok I can aggregate the errors then [17:45] and then they aren't really errors, oddly enough [17:45] just warnings [17:45] maybe put as separate attr? [17:46] well err is only checked for truthyness so I will just turn it into an array and push them into there [17:46] as right now it simply returns boolean and logs to the console [17:46] hatch but my point is that this is not an error condition [17:46] so this is actually adding more information than we had before [17:47] ohh I see [17:47] I'm not sure what would be an error then [17:47] yay, tests pass; my import cycle fears were unfounded [17:48] hatch, only error is if unit's service is subordinate: we can't do that [17:48] time to see if my merge fears can come true instead [17:48] yeah I didn't even know what that was lol [17:49] hatch, I think service has subordinate flag [17:49] puppet is subordinate hatch [17:49] because it runs on the same machine as a, uh, non-subordinate charm, and supports [17:49] you could have a logging charm too [17:49] it is something that is supposed to be able to support ither charms [17:49] oh ok - so is that something I should be taking into account? [17:49] other [17:50] nagios is another example [17:50] hatch, would be easy to: get the service and loog at the subordinate flag [17:50] look [17:50] alright I'll be sure to add that [17:51] hatch your logic in performOp_remove_units looks a bit weird in lines 385-386 [17:51] if (!res) then res.error would exist [17:51] it's because res is boolean [17:52] hatch, but an error object will also be truthy [17:52] I'd document the return values of removeUnits also in the pydoc thing [17:52] yeah so if (res.error) { data.err = res.error; } data.result = res; [17:53] hatch that would work if you changed the output of removeUnits, yes [17:53] hatch, think about what a reasonable reply from removeUnits would be in the abstract [17:53] yeah I think I'll try and mirror the other methods [17:53] to make it consistent [17:54] for instance, I'd be tempted to return a hash of {removed: [], notFound: []} *or* {error: ...} [17:54] but that's off the cuff [17:55] yeah I could do that if that's allowed [17:55] you said yesterday not to return any extra data than what's already there [17:55] so I was trying to stick to that :D [17:56] hatch, remember, there's a difference between fakebackend and pyjujuapi [17:56] oh right, fakebackend can return whatever [17:56] pyjujuapi only return the same stuff [17:56] fakebackend is just supposed to be helpful JS thing with helpful JS API including helpful JS responses [17:56] right [17:57] ok so check for subordinate and aggregate warnings [17:57] fix conditional [17:58] I assume you will use your new generateServices helper to refactor the add unit test from yesterday too [17:58] good idea [17:59] yep I will for sure [17:59] good work hatch, on the right track [18:00] thanks [18:00] * gary_poster returns to reviews [18:00]