[00:26] huwshimi: morning [00:27] morning huwshimi [00:27] huwshimi: we went through notes from the sprint and instituted a 2 review policy for branches [00:28] huwshimi: in order to build a bit of mentorship [00:28] rick_h__, hatch: Hey [00:28] rick_h__: Ah great! [00:28] huwshimi: also please make sure to add tags ot the cards to note who the reviewers are [00:29] huwshimi saw this and thought of you https://www.facebook.com/1025thebull/photos/a.116850054996026.20819.116054921742206/753390941341931/?type=1&theater [00:30] rick_h__: OK, what exactly do I add for the tags? [00:30] huwshimi just your name [00:30] er the reviewersname [00:30] Ah sure [00:31] hatch: Also, bears [00:31] lol! [00:31] huwshimi: the irc nick usually [00:32] OK np === uru_ is now known as urulama [07:05] * urulama changes location [08:05] morning frankban [08:06] morning urulama [08:09] frankban: do you know if actions are actually supported in core or are they just part of charm.v2 for now? [08:14] urulama: not sure [09:07] * urulama just got yubikey delivered ... 2FA SSO works as a charm now :D [09:53] urulama, frankban: fwiw, actions support in core is ongoing -- a bunch of the model is in place, the charm tools and the CLI/API bits are still in progress [09:53] fwereade: good to know, thanks [09:54] urulama, frankban: bodie_ and jcw4 in #juju-dev are the guys with the most up-to-date info because they're the ones doing it :) [09:54] fwereade: thanks. which schema are used? yaml or json or both even? [09:55] urulama, iirc it's using json-schema for validation, but it's represented in the charm as yaml -- but only things that can be represented as json and conform to the schema will be acceptd -- if that makes sense? [09:56] fwereade: it does, tnx [10:07] hi rogpeppe1 [10:07] rogpeppe1: just heading for lunch [10:07] * urulama lunches [10:38] morning [10:51] rick_h__: hiya [10:52] mornin' all [11:42] guihelp: I need two reviews + QA for https://github.com/juju/juju-gui/pull/462 anyone available? thanks [12:07] morning [12:07] morning bac [12:07] safe travels home? [12:07] yes, safe. long but safe. [12:08] * bac hides from huw [12:08] heh [12:08] i'm really looking forward to the direct flight to FRA! [12:08] bac: let's chat before the hangout to sync up. I wanted to catch you up on events from yesterday/today and then see what cleanup from the sprint you've got and such [12:08] 8 << 20 [12:08] lol [12:09] bac: if you get bored and caught up before my call this morning ends (10:30 ish) a live env test of frankban's branch would be +++1 [12:09] rick_h__: sure, just holler [12:09] https://github.com/juju/juju-gui/pull/462 [12:09] will do, bored or not [12:10] thanks bac [12:11] frankban: and we'll poke at the US JS folks for the review side [12:11] maybe jcsackett and hatch or Makyo [12:13] rick_h__: +1 [12:22] frankban: the vmware display checkbox you showed me has changed my life, or at least my vision. ty! [12:26] urulama: the action commands aren't exposed at all in 1.20.1, so while some stuff might be there, its practically useless [12:26] good morning ya'll [12:27] jrwren_: and morning :) [12:28] morning [12:42] jujugui added cards for expenses. For the first time expenser people let me know if you've got questions. [12:43] remember to file per diem, except for the team dinner night [13:28] rick_h__, frankban: i'm looking at the PR now. [13:29] jujugui: i need a second review on https://github.com/juju/juju-gui/pull/459 [13:30] jcsackett on it [13:30] hatch: thanks. [13:37] rick_h__ expenses filed [13:38] crap I forgot a day [13:38] lol [13:46] jcsackett done [13:46] kadams54 I added your nick to the tags for jc's card [13:47] Ah yes, sorry [13:50] hmm github created a new PR UI [13:59] hatch: yeah, seems like there's also some funkiness with avatars not showing up [14:00] frankban: i'm doing qa of your branch on ec2. in mv if i select 'move unit' i get two drop downs. one has '1' in it and the other 'kvm'. if i click on the dropdown i get a blank popup rectangle that never renders. is this due to your branch or another issue? i'm using chrome on trusty. [14:00] the tabs in the review now update the UI and change the addres bar but don't put history records in so the back button now FINALLY goes back to the pr list....yay! [14:01] frankban: some comments (mostly questions) on your PR. [14:01] bac: are you also reviewing frankban's branch, or just doing the QA? [14:01] jcsackett: i was asked to just qa [14:01] on a live env [14:01] bac: dig. [14:01] in that case... [14:02] frankban: you can see it here: ec2-54-187-78-196.us-west-2.compute.amazonaws.com [14:02] hm, actually, probably should hold off on calling for a follow up review until i'm actually completely done. [14:03] bac: not sure if that's my branch, never tried that path... I'll spin up an ec2 to check trunk [14:32] jcsackett lol, didn't agree with kadams54 and I? ;) [14:40] kadams54: never heard, did your laptop survive the water mishap ok? [14:40] Thus far [14:41] Typing on it right now :-) [14:41] niiiiiice [14:41] I forgot about that actually [14:41] that's good to hear [14:42] thems is pricey [14:44] frankban I'm a little curious about the `prepare` method - while I think it's a good idea to have something along these lines - could this not have been accomplished by setting the series on any parent when adding the unit? I think that follows how we have typically done things like this in the past. [14:48] I was pretty worried that my laptop was going to explode somewhere over the Atlantic, setting luggage on fire. The plane would make an emergency landing, I'd be whisked away to a CIA secret prison somewhere to interrogate me on my devious plot, and the rest of you would never hear from me again. [14:48] frankban: will you ping me when your branch lands? i want to check for that blank pop-up on comingsoon. [14:48] hatch: that's another way to do that. I ended up with prepare so that we can avoid the clean up dances in the case the unit is unplaced. It seems to me more maintainable if we reduce the times/places where a record is mutated. [14:48] hatch: huh? [14:49] bac: sure, now I am in the middle of a review, will look at my branch later [14:49] frankban good idea, we should revisit the other places where using this prepare strategy will make it a little nicer as well [14:49] jcsackett oh you didn't make the change that kadams54 and I requested, just landed it without comment :P [14:50] hatch: i did make those changes. [14:50] hatch: sorry, it seemed trivial so i made the change, rebased into clean commit, and landed. [14:51] jujugui call in 10, kanban please [14:51] jcsackett ohh odd, the diff didn't show it [14:51] maybe GH is just being wonky [14:52] hatch: it's the line below your comment (the @return) if you look at the files changed. [14:52] hatch: oh hell, your other comment didn't show until just now. [14:52] ...i *really* have issues with github comments showing up. [14:53] lol [14:53] hatch: and i don't agree, though. [14:53] there's not identical paths. [14:53] _selectMachineToken and _selectContainerToken are entirely different fn's. [14:53] son of a [14:53] ok you win this one eyes [14:53] * jcsackett laughs [14:54] i'll spot you not seeing that if you spot me not seeing your comment. :p [14:54] haha ok deal [14:57] jujugui call in 2 [14:58] frankban: your comment arrived *just* after i'd entered :shipit: ... [14:59] frankban: will fix in next branch [14:59] frankban: jcsackett bac jrwren_ call [15:17] rick_h__: did you want to catch up as you mentioned earlier? [15:23] bac: definitely, I've got a marketing meeting in 7, after that? [15:24] rick_h__: sure [15:24] rick_h__: how long is that? [15:24] bac: 30min but usually pretty fast as we've got nothing to report atm [15:24] ok [15:24] bac: if you want to agree to meet post-lunc or something feel free [15:24] even put somtehing on the calendar, after this I'm free for the day [15:24] busy morning, open afternoon [15:24] 1pm would be better [15:25] k, sounds good [15:25] i'll create a calendare [15:25] ty much [15:25] s/e// [15:25] rick_h__: still no movement on the PR, FYI [15:25] rogpeppe1: ok, after this next call I'll look. [15:25] rick_h__: ta [15:25] maybe jrwren_ or jcsackett or bac can help poke at it in the meantime [15:26] wtf, the last charmstore ci run was July 2? [15:26] rick_h__, rogpeppe1 i'll look at jenkins [15:26] bac: ty [15:27] ah ok, the merge one though has run a day ago [15:34] rick_h__: is there a hook on github that has to be enabled? i'm not an admin on juju/juju-gui nor juju/charmstore so i cannot investigate. [15:34] rogpeppe1: can you make me an admin on github for juju/charmstore? [15:37] bac: looking, yea juju core turned everyone off but leads [15:37] I was adding our team back in second [15:37] rick_h__: but there is some hook that needs to be setup, right? [15:38] bac: right, a webhook or it can be configured to do polling via cron [15:38] but that's sub optimal [15:38] rick_h__: i'd prefer the hook [15:38] but that's why its just sitting there [15:38] bac: ok, updated uiengineering perms [15:38] see if you can see now [15:38] bac: sure [15:39] bac: what's your github username? [15:39] rogpeppe1: he should have it now [15:39] bac [15:39] rogpeppe1: bac [15:40] yes, i do [15:40] rick_h__: is the same payload URL used for all projects on that jenkins instance? [15:41] bac: I think so, it's got a key in it to match the github project name to tell them apart [15:41] bac: but not 100% on that one [15:41] ok [15:44] rogpeppe1: FWIW review done [15:44] frankban: thanks a lot [15:44] mp [15:45] frankban: i'll introduce some more comments [15:45] rogpeppe1: it would be great [15:47] urulama can't make up his mind whether to join or leave :-) [15:48] rogpeppe1: just joined ... did it sign me on and off all the time? [15:48] urulama: you joined then left, then joined again [15:50] anyone know if it's possible to get github to email copies of my own comments as well as other peoples' ? [15:51] it's awkward having the email thread without being able to see exactly what people are responding to [15:52] rogpeppe1 not I have found [15:52] hatch: ok, ta [15:52] in the same vein however launchpad also desn't send those emails [15:52] or include links to the branch/pr in question lol [15:52] hatch: yeah, but codereview did [15:52] ahh right [15:53] gh could do so much better than they are doing [15:53] it's sad really [15:57] rogpeppe1: i see your pr 34 from yesterday was picked up and merged properly. [15:58] bac: yup, that worked fine [15:59] rogpeppe1: i'm running the jenkins tester manually. the one that should've been run when you submitted the PR. when it finishes i'll run the merge one manually too. [16:00] bac: thanks [16:00] rogpeppe1: on github should we change the default branch to v4? [16:00] bac: do you think the problem will have gone away now? [16:00] rogpeppe1: no reason to suspect that for the merge job [16:01] bac: i'm not sure. it's still broken from the point of view of someone that actually wants a charm store [16:01] rogpeppe1: i don't understand [16:01] bac: also we're going to rename the branch to v2 [16:02] bac: if someone types "go get github.com/juju/charmstore/cmd/charmd" it should currently work [16:02] jcsackett: could you please ping me when my review is done? [16:02] bac: but if we change the default branch, i don't think it will [16:02] rogpeppe1: ok [16:04] rogpeppe1: are you going to push again with frankban's suggestions? if so, why don't you delete your :shipit: comment, push, and then add :shipit: back [16:04] bac: i was going to add the comments at my leisure. i'd like to get it pushed before then. [16:11] bac: but if it would make life easier for you, i can easily do what you suggest [16:14] rogpeppe1: if you did as i suggested i could watch to see if it triggered and if not, i would start a manual build. but if your code is ready to land now i can trigger a manual build with that revision [16:17] bac: i've re-added the :shipit: [16:20] urulama: i'm considering changing things so that GET /$id/meta/$something just returns nil if $something is not relevant to $id (for example when trying to get bundle metadata from a charm) [16:20] urulama: that would make it more consistent with the any anypoint [16:21] urulama: but might be unpalatable to some [16:21] urulama, rick_h__, bac, frankban: what do you think? [16:22] rogpeppe1: hmm, I'd prefer to look if we can make the payload a common key and let the client decipher. Rather than bundle metadata, it's just metadata and you can get the same key from charm/bundle but with different contents clients can easily pick up on [16:23] rogpeppe1: but that's top of the head response [16:23] rick_h__: i'm not quite following you there [16:23] rogpeppe1: i'd think the client would want to know an irrelevant request had been made as it would indicate it was in error. [16:24] a nil response would mask the error on the client side [16:24] rogpeppe1: sorry, was thinking more in a group response (search result, multiple ids, etc) [16:25] bac: it's not necessarily an error - it just indicates that the requested metadata isn't relevant for that id (which is not necessarily something you can tell from the id) [16:25] right, because of the flat namespace [16:25] rogpeppe1: so my question is what bits of data to not apply? [16:25] * rick_h__ loads up spec [16:26] bac: and we specifically allow something like: GET meta/any?id=wordpress&id=somebundle&include=charm-metadata&include=bundle-metadata [16:26] rogpeppe1: and I'd propose not to have charm-metadata and bundle-metadata, but a single metadata [16:26] bac: (the irrelevant results are just omitted from each id as appropriate) [16:26] rogpeppe1: ok [16:26] so that you'd say 'any/id=xxxxx&id=yyyyy&include=metadata [16:27] and you'd have that key in all results [16:27] rick_h__: i don't think that works so well [16:27] rick_h__: because then you don't know what type you're expecting [16:27] rogpeppe1: they specified an id, they have some clue. And it's easily decernable on the client end [16:27] rick_h__: the rule is (currently) given a metadata endpoint, you know exactly what type you're going to get [16:27] rick_h__: and that works really well with Go [16:28] rick_h__: it means you don't have to any dynamic shenanigans to try to duck-type the response [16:28] rogpeppe1: IIRC in the any endpoint it's easy for the client to understand if the requested key is not relevant, the corresponding meta field is missing. I'd be +1 on doing the same with the single call it's clear when the data is not relevant (nil?) vs the data is empty [16:28] rogpeppe1: well implementation language aside, it seems crazy to me to have to specify the charm- and bundle- in that request. Not only did I tell you I want the metadata for bundle1234 but that I want bundle-metadat vs charm-metadata? They're mutaully exclusive [16:29] rick_h__: metadata isn't the only field that is bundle- or charm-specific [16:29] * frankban bbiab [16:29] rick_h__: for instance, bundles-containing is only relevant to charms [16:29] rogpeppe1: ok, so it's an implementation simplicafication vs a user experience simplification that we're disagreeing on. Which to prioritize it seems? [16:30] rogpeppe1: ok [16:30] but then we'd allow a bundle id to be passed to that end point without any notification to the user that it's not a valid argument? [16:30] rick_h__: which is simpler is somewhat subjective, i think [16:30] rogpeppe1: I agree it's subjective. [16:31] rick_h__: currently we have a strong invariant in the API that the client knows exactly what data to expect back for a given endpoint [16:33] when the json data is cast to mongo models is the metadata not able to be determined/created at parse time? I mean you're either going to have a lot of checks in the code for 'xxx.bundle-metadata is not nil' or 'xxx isBundle' either way? [16:33] rick_h__: i *think* returning nil is reasonable - a valid bundle will never have nil metadata, so it's easy for the client to determine what it means [16:33] a charm will have nil metadata? [16:34] rick_h__: a charm has a nil *charm.BundleData but a non-nil *charm.Meta [16:34] rick_h__: in the entity doc [16:34] rick_h__: there are no "is-not-nil" checks necessary. [16:34] ok, so if uros and frankban are on board I will defer. I'm not a fan and it seems like Go leaking into ideal functionality of the api, but oh well I suppose if everyone else agrees. [16:35] rick_h__: another one: should we return an error if the client asks for a charm's actions but there are none? [16:35] so the api is http. If you ask for something and it's part of the main url, you'd get a 404 I'd imagine [16:35] however, an a bulk call the request was successful, however, some recoreds might not have that data [16:35] so an empty set [16:36] rick_h__: yeah, it's the conflict between bulk api calls and normal calls that i'm trying to reconcile [16:36] rogpeppe1: understood [16:36] rick_h__: it would actually be easier for me to consistently return a 404 error for any data that happens to be nil. [16:37] rick_h__: but i *think* it's nicer not to [16:37] rick_h__: as the endpoint is really found - it just doesn't have any data stored there [16:37] but this is what I mean. If the user is passing a list of mixed ids, and asking for an array of metadata in a single call, 404'ing because one item doesn't have data X seems broken [16:37] rick_h__: definitely [16:37] rick_h__: that's why the API specifies that irrelevant results are omitted [16:38] however, if I ask you for the field X on id Y and it's not there, 404 is the standard [16:38] so I'd never expect a bulk call to return a 404, but a single I would. [16:38] what else would you send back, just a {} [16:38] rick_h__: just null. [16:38] you'd not have an idea if the id wasn't found, or there was no metadata, or that it's there but nothing [16:38] it needs more context in a single call imo [16:39] if we were to go against http and always return a value, we'd need to return a message as to what happened [16:39] rick_h__: if you get null, you know that the id was found and the metadata endpoint was recognised, but there was no metadata [16:39] and if the id was not found you get a 404? [16:39] rick_h__: yup. [16:39] and if there was metadata, but it was defined to be an empty set, you'd get {}} [16:39] ? [16:39] rick_h__: and if the endpoint wasn't found, you get an error [16:39] rick_h__: (currently a 500, but that will change) [16:40] well if the endpoint wasn't found the router would 404? [16:40] rick_h__: not currently [16:40] e.g. unroutable request, a 500 implies server side issue [16:40] rick_h__: but it will [16:40] ok, well I think it'd be good to define these cases and write out the suggested path for each [16:40] make sure they're no conflating (one response type could be X or Y) and then review with the team? [16:41] rick_h__: yes, this should definitely be better specified in the API doc [16:42] rogpeppe1: thanks, I think I see where you're headed and it's probably the path, apologies for not being a huge fan and getting difficult. :) [16:42] sometimes takes some convincing [16:42] frankban I have finally finished reviewing your branch - take a look and feel free to comment whererever necessary [16:42] rick_h__: that's fine - i see where you're coming from too :-) [16:44] frankban: sorry, hadn't seen that you had replied to my points. +1 from me, looks like hatch has some points still unaddressed. [16:44] rick_h__: at the moment, i'm leaning towards returning 404 with a "no data found" message for any metadata that == null; and defining bulk endpoints to omit all null entries. [16:45] rick_h__: that way, if a client cares, they can at least distinguish the 404 errors, but there's a clear and defined correspondence between single endpoints and bulk endpoints [16:46] rogpeppe1: rgr [16:46] rick_h__: rgr? [16:46] sorry, that's probably not a term to use with a guy named roger [16:46] rick_h__: lol [16:46] rgr == 'roger' [16:46] sorry, grew up military [16:47] rick_h__: not an abbreviation i've seen before [16:47] rick_h__: which is strange, really [16:47] I used to use it a lot more, but tried to stop since you've started [16:47] but once in a while leaks out of my brain [16:48] rick_h__: i don't mind - "roger" has a few meanings :-) [16:48] rick_h__: how did you put those red "awaiting approval" sections in the bundle specification document? [16:49] rogpeppe1: not sure I see the same thing. Nothing red [16:49] there's some 'awaiting approval' because I don't have edit rights [16:49] I can only 'suggest' [16:49] rogpeppe1: which shows to me as green [16:49] rick_h__: ah, i see [16:49] rick_h__: i see it as red [16:49] rick_h__: but i'd quite like to do the same with the API proposal, so that you and others can see the proposed changes [16:50] so in the upper right [16:50] there's a drop down to swich modes [16:50] switch modes [16:50] "editing, suggesting, viewing" [16:50] you can use that to 'suggest' I believe [16:53] can you give example where you are thinking of returning 404? [16:53] oh... e.g. such as GET ubuntu/meta/nope [16:53] yes, that makes good sense [16:53] right [16:54] /mysql-13/meta/bundle-metadata [16:54] is that a nil, {}, or 404? [16:54] is part of the idea [16:54] yeah... tough call. [16:54] and /meta/any?id=mysql-13&include=bundle-metaadata [16:54] how does that differ? [16:54] i can see how that would differ [16:55] /mysql-13/meta/bundle-metadata should 404 if /mysql-13/meta did not include "bundle-metadata" in the response [16:56] right, that's what we're chatting about [16:56] /meta/any should never 404 IMO, because that path exists. the query may not be valid, but that is not a 404 IMO [16:57] right === jrwren_ is now known as jrwren [16:58] and I got sidetracked on helping not have nil's in the return bodies because charms/bundles have the same idea (metadata) but they're different sets of fields [16:58] however I'm learning that my ideal duck-typing python ways might not be friendly to our work [17:09] bac: that PR still doesn't seem to have attracted any attention from the 'bot [17:12] jcsackett, hatch, thanks for the reviews [17:13] hatch: replied to your comments, do you want placeUnit to return (not raise) an error? [17:13] frankban thanks [17:14] frankban well we don't use the try/catch technique anywhere else in the GUI so it's not really a pattern we are used to [17:14] I think I'd prefer it to return to follow some kind of convention [17:15] hatch: no problem, I'll change it, and that's actually a good point [17:16] great thanks [17:16] frankban with all the Go you've been doing I'm surprised you went with the 'throw' vs a return by default ;) [17:18] hatch: haha, you are right [17:18] :D [17:19] rogpeppe1: ack. will push it manually when i get off the phone [17:19] bac: ta! [17:20] hatch: anyway, more than once while writing this branch I tried to avoid using var by doing "x := value"... [17:23] frankban haha it is a nice syntax :) [17:28] * rogpeppe1 is done for the day [17:29] g'night all [17:30] night rogpeppe1 [17:52] bac: another thing we might look at is duping the jobs and setting one up for master and another for v4/v2 [17:52] so that there's less cross contamination potential [17:52] jujugui: going to step away for a walk. biab [17:52] rick_h__: ack. i just discovered there is no develop.ini file... that could be a big issue. [17:53] bac: development.ini? [17:53] yes [17:53] it can't work without one so must have been there. :/ [17:53] interesting [17:54] rick_h__: i'm surprised anything works. especially if that file didn't get recreated when we brought the env back up [17:54] bac: right, no idea how that works since it holds the keys [17:54] and gui landing is working? [17:54] no, its there [17:54] oh, but the charmstore isn't in the list of projects? [17:55] in that ini file? [17:55] i was looking in the workspace version of the lander not /var/lib/jenkins/jenkins-github-lander [17:55] ah ok [17:56] yes, charmstore is correctly in that file [17:56] rick_h__: sorry, go walk [17:56] bac: heh all good thanks [17:57] hatch: approved your holiday. In the future please not the name of the holiday in question [17:57] Makyo: also got yours [17:57] and now I run away for a bit [17:57] rick_h__ ok will do thanks [18:02] bac: FYI, I just :shipit: the GUI branch, hopefully it will get merged soon. done for the day, have a good evening! [18:13] urulama: still around? [18:15] jujugui: found the jenkins problem. this PR https://github.com/juju/charmstore/pull/23 has an unknown source repository, which breaks jenkins. [18:16] jujugui: anyone know how this happened? just deleted the repo on github? [18:19] hatch: ^^ [18:20] yeah the source repo was probably deleted but the pr was left [18:20] although the jenkins thing should probably be resilient enough to handle that :) [18:25] yeah [18:25] bac: hi, around somewhere ... yes ... my fault for doing that early in the morning ... was trying to delete a branch that is not forked from charmstore, but ended up deleting the wrong one [18:25] urulama: ok, just gathering information for my bug report upstream [18:25] bac: didn't think it will break up CI :( [18:26] urulama: not your fault [18:26] * urulama puts on a "dunce" hat for today [18:27] * Makyo -> appointment [18:28] bac: i'll probably close 40 as well, as 39 completely breaks how tests are done ... [18:33] huh, looks like rick_h__ *is* the upstream... [18:37] this is me grumbling about being a go nube. *grumble* [18:37] rogpeppe1: your pr/39 got merged. [19:45] bac: yes, that's my tool from when we first did GH move [19:45] bac: thanks for locating that [19:46] rick_h__: i've also installed mailutils and added a MAILTO to the cronjob so i'll get email when the cronjob fails [19:46] if it works [19:46] bac: woot [19:52] * rick_h__ goes off to get the boy for swim class. [20:10] rick_h__, is there a way we can just blow away oneiric from the store? [20:16] jcastro short answer is no [20:17] it can be done but will require work to do so [20:19] jcastro the branch which I'm about to propose puts the charms that match your environment first in the autocomplete list [20:19] I mean more for search results [20:19] though that does sound useful! [20:20] like, I search for phpmyadmin and I always end up one one-eyed-rick instead of precise/trusty [20:20] lol one-eyed-rick [20:21] but yeah so that will change soon but to remove the oneric ones from the store requires quite a bit of launchpad/charmworld work [20:21] PR's accepted? ;-) [20:31] jujugui: charmstore and charmstore-merge CI are temporarily not pissy. [20:31] http://ci.jujugui.org:8080/job/charmstore/31/console [20:31] that one was run by magic [20:31] as it should be [20:32] jcsackett: is your ci happy? [20:34] bac: it is, for the time being. [20:34] bac: see other channel for some discussion of what was going on with it. [20:37] jujugui lf a review and qa for https://github.com/juju/juju-gui/pull/463 plz and thanks [20:53] hatch: so services have an attr called unit_count, which we manually update every time we add or remove a unit...what do you think about giving that a getter which just gets the count from the services unit list? [20:54] jcsackett I thought we listen for change events on that? [20:55] not to update unit_count. all the references to it have it being set when we add something. just did an ack across the code base to check. [20:56]