[03:58] thumper: a quick look at the recent 1.25 CI failures seems to show a smattering of 1 off issues, from EOF pinging mongo to directory permissions etc. doesn't appear to be too much that's a systemic juju failure [05:02] anastasiamac_: just running a little late, will be there in a minute or so [05:02] jam: nps :) [06:20] Bug #1471657 opened: linker error in procsPersistenceSuite unit test on ppc64

[09:01] voidspace: hangout time! [09:01] dooferlad: sorry was on a phone call [09:01] fwereade: ^^ [09:09] dooferlad: http://reviews.vapour.ws/r/2103/ [09:41] fwereade: http://reviews.vapour.ws/r/2078 has an "The file 'state/collections.go' (rcf5bc23) could not be found in the repository" error about 3/4 of the way down. I don't know who can prod the server, but my guess is it is out of disk space again. [10:10] dooferlad, I *think* that's just because RB can't handle me renaming it to collection.go :/ [10:11] dooferlad, the diff *is* a bit smaller than it looks because some of it was just that move to collection.go -- but it did change as it moved as well, I'm afraid [10:12] fwereade: not to worry - it is new to me. [10:17] fwereade: ping about your PR? [10:17] jam, yes [10:17] fwereade: I'm a bit surprised to add EnvironTag as the first param of state.Open [10:18] though I suppose some of that is coming from languages that have optional params so you can fill them with stuff to avoid breaking the API. but it does feel like it is a clarification on mongoInfo vs being the most prominent bit of information. [10:18] jam, well, a state *is* specific to an environment now [10:18] jam, I don't think the mongoInfo specifies that? [10:19] fwereade: I'm guessing the moved Open function is in collections.go ? I keep looking for the change in the diff, and best guess it is the missing file [10:20] jam, the intent is just to make it a bit more explicit -- anyone connecting to a state really ought to know what env they're talking about -- rather than insertinng it magically and internally [10:20] jam, state/open.go [10:20] jam, it's a 2-pager :( [10:20] ah [10:20] jam, I'm still a bit bothered about magical internal serverTag-setting [10:26] fwereade: I'm not sure I'm aware of the magical serverTag setting. Though I do see it getting set. [10:28] jam, I'm not fully conversant with its purpose [10:29] jam, afaics adding env-awareness just meant adding those 2 fields and setting them wherever was conveniennt [10:29] fwereade: and the move for "not authorized" was a real-world case of hitting an error that didn't end up as a QueryError from mongo? [10:29] jam, yeah, it was a *LastError as it happens [10:30] fwereade: it feels like something that needs a bit more documentation so that we know why and someone doesn't just refactor the fixes away [10:30] fwereade: assuming we don't have good ways of triggering those cases. [10:30] jam, sgtm [10:30] jam, if someone breaks it it will fail intermittently because we interact with the collections in map ordering [10:30] jam, and they fail in all manner of excitingly different ways [10:31] jam, so, yeah, I will add to the documentation [10:32] fwereade: 2 page diffs make me sad... [10:32] jam, me too :( [10:33] fwereade: just grabbing a local copy and vim. at least I can jump around and search more easily [10:33] I like inline comments, but navigation is hard [10:33] jam, yeah, a lot of it is just that EnvironTag addition, but it obscures the meat [10:34] yeah [10:36] fwereade: I notice we don't explicitly create the txns.stash and txns.purge? (added by menno, IIRC). [10:36] not much with what you did, but just one of those "we create all the collections here" except the ones we don't. [10:36] jam, I explicitly turned my head away from that rabbit hole [10:37] jam, we create the same collections we did before and that's all I know [10:37] jam, I *think* txns.log is the only important one [10:37] txns.stash is created by mgo [10:37] jam, and quite possibly not even created explicitly? [10:37] and txns.purge? was our bookkeeping page for when the last purge was run/how much it cleaned out/etc. [10:38] fwereade: mgo/txn does a "C.database.name + ".stash") sort of trick. [10:38] created under the covers. [10:38] jam, it would indeed be good to add those as rawAccess collections just to make it clear that they shouldn't be touched [10:38] jam, yeah, indeed [10:40] fwereade: a thought… what about changing the comment strings in allcollections.go into string attributes on the collectionInfo structs? [10:41] jam, I wanted to do that and then couldn't quite convince myself it was that useful [10:41] jam, so I like the idea, but can you explain why? ;) [10:42] fwereade: large lists of metainformation feels like something you could use to automate documentation about said information [10:42] harder to scrape comments than write a "for foo in collections" sort of loop [10:42] but someone would actually have to write that part [10:42] jam, I counter "YAGNI", but I like the idea enough I think I'll do it ;p [10:43] fwereade: I can certainly see people asking "what is the layout here" and we can just point them at allcollections.go [10:43] it *feels* useful to be able to programatically pull that out somewhere else, but as you say YAGNI until someone actually does something with it. [10:43] jam, yeah, just putting that information together feels like the big winn [10:43] at which time they could turnt hem into strings [10:44] fwereade: ugh.. leaseC vs leasesC being multi-aware vs not. [10:44] +2 on deprecating that ASAP. single-character typos having bad consequences [10:44] jam, I just started the branch to tear that out by the roots :) [10:45] jam, the plan is basically to go around wantonly deleting code until I get tired, and then see what needs to be done to patch it up [10:46] jam, at the very least I'll change its name to doNotUseThisDeprecatedLeaseC [10:46] thisIsNotTheLeaseYoureLookingForC [10:46] :D [10:49] fwereade: so ATM we have no raw-access collections, just a place to put them? [10:50] jam, yeah [10:50] jam, have agreed with wallyworld that status-history in particular wants to go there [10:50] jam, thought I'd prepare the ground since I was there ;) [10:52] fwereade: so you logically split the groups up based on comments and layout in the file. Would there be a reason to have collectionSchema itself somehow be split up into different attributes? [10:54] jam, perhaps, but (1) I'm not sure entirely sure where we'd use them and (2) I'm not certain that that organisation is fundamental [10:55] jam, the thing that's scratching at the back of my mind is that we use several databases anyway [10:55] jam, and collectionSchema is only a step in a hopefully-good direction [10:55] jam, it doesn't cover everything yet and baking in *too* much structure might not be ideal [10:56] fwereade: sure. Just that the layout doesn't inform you that this collection is/isn't raw accessible. Presumably the higher-level Runners do those checks? [10:57] jam, the rawAccess attribute is the only thing that controls that -- and, yeah, it's the multiEnvRunner that pays attention to it [10:58] jam, and there's an empty branch in envStateCollection for somehow preventing .Writeable() access to non-raw-access collections [10:59] jam, but that's not done mainly because we still have no shortage of direct .Writeable access to non-raw collections [11:02] jam, (incidentally -- I feel like envStateCollectionn failing to strip env-uuid off ids on load is a bit squicky -- it causes all that nasty maybe-insert-env-uuid stuff which is just asking for subtle bugs imo) [11:02] jam, (concur? don't have time to do anything about it, just thinking aloud) [11:03] fwereade: I haven't specifically dug into it, but from your description it definitely sounds like a leaky abstraction [11:03] and a case for "I read this ID and I pass it back in and read it back again" and they don't all agree [11:03] menn0, hey, in case you're awake, did we take Settings into account when we did the multi-env stuff? [11:04] jam, yeah [11:04] menn0, hooray, we did [11:05] fwereade: I was pretty sure we did [11:05] * menn0 not working, honestly [11:05] :) [11:06] menn0, I can pontificate about how we could have done it *even better*, because none of our user can call things in settings "env-uuid" any more [11:07] menn0, and I'm not 100% sure how that would play out in practice, but I'm pretty sure it would be no fun [11:08] menn0, we've been flirting with disaster there with txn-revno et al since forever, but env-uuid feels like the sort of name someone might be a smidgen less unlikely to actually use? [11:08] menn0, anyway, you are not working, I will stop talking ;p [11:08] fwereade: i'm working a little kinda... while also making soup and doing some non-work jobs [11:09] * fwereade knows how that goes :) [11:09] * fwereade is not expecting anything resembling snappy repartee [11:09] * fwereade coffee actually [11:09] fwereade: just getting a windows hyperV VM set up to do windows builds and test runs [11:12] fwereade: thinking about the possibility of a name collison on "env-uuid" [11:12] fwereade: it seems most likely for settings [11:12] er, what is theis failure trying to tell me? http://paste.ubuntu.com/11830352 [11:13] fwereade: almost everywhere else we have a struct which will already have env-uuid on it [11:13] fwereade: and it'll be fairly obvious what it's for [11:14] fwereade: maybe for settings there should be a check to block exernal uses of env-uuid, txn-revno etc ? [11:14] mgz: the HasLen failures are a little hard to read... [11:15] mgz: it's showing you that it got an empty slice of *syslog.Writer but it expected a length of 2 [11:15] menn0: aha, thanks [11:16] mgz: the obtained line is showing you the full actual thing that was obtained [11:16] mgz: not very clear though [11:19] menn0: have a TestPrunes failure on ggco, do you want me to reopen bug 1459291 or open a new bug? [11:20] mgz: can you pastebin the output for me? [11:21] menn0: http://reports.vapour.ws/releases/2858/jub/run-unit-tests-trusty-ppc64el/attempt/3490 [11:22] mgz: that gives me a 404 (and I am logged in) [11:23] s/jub/job/ [11:23] sorry, I have irc on a different machine and it makes passing links around dodgy :) [11:26] mgz: aww but I wanted to see the jub :) [11:26] ehehe [11:26] mgz: regarding the problem... pls create a new bug [11:26] okay. [11:27] mgz: I've seen this before and could have sworn I had already created a ticket [11:27] mgz: ah, no, there it is in my personal todo list [11:27] mgz: pls assign the bug to me [11:32] menn0: done, bug 1471770 [11:32] Bug #1471770: TestPrunes fails occasionally still

[11:34] mgz: tyvm [11:35] menn0: both failures I have since your fix are on the ppc64 tests [11:39] * fwereade ended up having lunch too [11:39] menn0, fwiw, what we should do is put the actual settings in a subdocument, and just makie sure we escape the keys properly [11:40] morning [11:40] fwereade: that would work nicely too [11:41] and has the added benefit of not limiting the keys so much [11:41] menn0, it's always just been one of those copious-free-time bugs :/ [11:42] fwereade: would lookups be slower in a subdocument? you don't get the default index on _id then right? [11:42] menn0, surely _id would jsut stay at the top level with the others [11:42] menn0, I'm not sure we'd need to index settings by content? [11:43] fwereade: i'm probably not understanding what you mean then (and I'm tired) [11:43] * menn0 hasn't looked at how settings are stored very much [11:44] menn0, it's just a document with everything jammed into the top level alongside the metadata :/ [11:44] menn0, it was a useful type in python, against zookeeper [11:45] menn0, as we switched languages and backends it gradually made less sense but was always basically just a straight port [11:48] Bug #1471770 opened: TestPrunes fails occasionally still

[11:48] Bug #1471771 opened: After "juju destroy-service " is executed, the corresponding Windows charm service is not uninstalled

[11:48] fwereade: ok, right so there's a doc per env [11:49] fwereade: so a subdocument would be fine [11:49] menn0, settingsC has *so much* in it [11:50] fwereade: a smaller, but grosser, change would be to translate the sensitive field names into other ones for storage [11:50] menn0, at least one set of config settings per service; at least one per relation unit that's entered scope; env settings, probably more I'm not immediately thinking of [11:50] fwereade: that is a lot [11:51] fwereade: any danger of hitting the 16MB limit? [11:51] menn0, oh! [11:51] menn0, no, each of those things is its own N documents [11:51] menn0, the collection holds a lot, so a lot of things are affected, is my only point [11:51] fwereade: ok so not one doc per env [11:52] fwereade: that's not so bad then [11:52] * menn0 should stop discussing this subject when he hasn't looked at the code [11:52] menn0, yeah -- I got thrown because, well, there *is* one environment settings doc per environment, but that's not what we meant :) [11:52] * menn0 also really needs to go to bed. soup is cooked, windows VM is set up. [11:52] menn0, sleep well, thanks for the conversation [11:53] fwereade: no worries. i don't think I contributed anything useful :) === psivaa is now known as psivaa-afk [12:07] perrito666, apiserver/common/getstatus.go:163 [12:08] perrito666, it looks like the query is a list of unit tags but it tells us information about some other entity [12:08] perrito666, if we want to know service status, why are we not passing service tags? [12:09] Bug #1471775 opened: TestModeForwarding occasionally fails

[12:13] voidspace, TheMue: Review please: http://reviews.vapour.ws/r/2105 [12:13] dooferlad: ok [12:15] fwereade: iirc, implements StatusGetter [12:15] perrito666, right, that just means it accepts a list of entities annd will tell yuo their status, assuming you're properly authed [12:15] perrito666, why does it accept a list of entities and tell you the statuses of some *other* enntities? [12:16] dooferlad: looking [12:16] fwereade: oh? [12:16] * perrito666 put on glasses [12:18] sorry brb kee ptalking [12:24] fwereade: service status returns status of a units service (and its units), you need to pass in the leader unit tag, I feel your question is a bit more complex than my answer, right? [12:25] dooferlad: "return None" is slightly confusing :-) [12:25] dooferlad: just to my Python addled brain... [12:25] dooferlad: one comment so far [12:29] dooferlad: and added another one ;) [12:30] perrito666, the question is -- why do we expect service status to come back when we ask for unit status? [12:30] perrito666, it's fine to restrict auth to the leader unit [12:31] perrito666, but that's a property of the connection, not of the request [12:31] perrito666, we already know who's connecting, and can use that information to decide whether or not to give out information about X entity [12:31] perrito666, but this *doesn't* implement StatusGetter [12:32] perrito666, because StatusGetter is supposed to tell you the status of the thing you asked for [12:32] nope, it implements ServiceStatusGetter [12:32] I am now reading the rest of the code [12:33] perrito666, ...we already had a StatusGetter [12:33] perrito666, it only handed out unit statuses, because those were all that existed [12:34] perrito666, whether or not to hand out service statuses is purely an auth-level problem [12:34] perrito666, the StatusGetter is not a *Unit*StatusGetter [12:35] perrito666, it just accepts entities and returns their statuses [12:35] perrito666, if they have them, and if the current user is authorized to know whether they even exist [12:36] perrito666, make sense? [12:37] fwereade: not really, I feel like entering in a mid sentence conversation here [12:37] * perrito666 goes and re reads the whole file to make sure we are talking about the same here [12:38] perrito666, heh, context is removing juju/juju/lease and seeing what failed [12:40] perrito666, getstatus.go was the second one; reading it, I got confused, and am not seeking understanding [12:40] s/not/now/ [12:43] quick hangout? [12:44] I have 15 mins before my next meeting [12:44] (but you are not allowed to laugh on my winter clothing) [12:44] perrito666, sure [12:45] perrito666, would you start one please? [12:45] sure hold a sec [12:46] perrito666, actually 2 mins coffee refill [12:46] k [12:48] fwereade: https://plus.google.com/hangouts/_/gzh5yzfc4533ewopliwwbc62wya?hl=en [13:42] dooferlad: commented your question [14:13] TheMue: diff updated [14:17] dooferlad: already pushed? cannot see it [14:18] TheMue: doh! wrong branch. One moment. [14:18] *lol* === kadams54 is now known as kadams54-away [16:01] dooferlad: voidspace: hangout === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === liam_ is now known as Guest20028 [18:11] fwereade: ping [18:55] Bug #1471242 changed: juju upgrade-juju to 1.24.2 fails with "invalid series: wily"

[18:55] Bug #1471936 opened: suite.TestRunCmd shows script failure

[18:55] Bug #1471941 opened: widows unit tests fail because handles are not avIlable

[22:23] Bug #1470714 changed: Ubuntu downloads are non-obvious === kadams54 is now known as kadams54-away [22:50] Bug #1470876 changed: Deploy --to zone=

[22:50] Bug #1472004 opened: agent-state error yet unit logs show no error [23:20] Bug #1472009 opened: manual provisioning with juju requires systemd-services [23:20] Bug #1472014 opened: juju 1.24.0: wget cert issues causing failure to create containers on 14.04.2 with lxc 1.07

[23:20] wallyworld: anastasiamac I completely blanked out === jog_ is now known as jog [23:23] perrito666: we are in standup if you want to join :-) === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [23:46] fwereade: i will hang around in our standup hangout in case you do join === kadams54 is now known as kadams54-away