/srv/irclogs.ubuntu.com/2015/07/06/#juju-dev.txt

wallyworldthumper: 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 failure03:58
jamanastasiamac_: just running a little late, will be there in a minute or so05:02
anastasiamac_jam: nps :)05:02
mupBug #1471657 opened: linker error in procsPersistenceSuite unit test on ppc64 <ci> <ppc64el> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1471657>06:20
dooferladvoidspace: hangout time!09:01
voidspacedooferlad: sorry was on a phone call09:01
jamfwereade: ^^09:01
voidspacedooferlad: http://reviews.vapour.ws/r/2103/09:09
dooferladfwereade: 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.09:41
fwereadedooferlad, I *think* that's just because RB can't handle me renaming it to collection.go :/10:10
fwereadedooferlad, 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 afraid10:11
dooferladfwereade: not to worry - it is new to me.10:12
jamfwereade: ping about your PR?10:17
fwereadejam, yes10:17
jamfwereade: I'm a bit surprised to add EnvironTag as the first param of state.Open10:17
jamthough 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
fwereadejam, well, a state *is* specific to an environment now10:18
fwereadejam, I don't think the mongoInfo specifies that?10:18
jamfwereade: 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 file10:19
fwereadejam, 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 internally10:20
fwereadejam, state/open.go10:20
fwereadejam, it's a 2-pager :(10:20
jamah10:20
fwereadejam, I'm still a bit bothered about magical internal serverTag-setting10:20
jamfwereade: I'm not sure I'm aware of the magical serverTag setting. Though I do see it getting set.10:26
fwereadejam, I'm not fully conversant with its purpose10:28
fwereadejam, afaics adding env-awareness just meant adding those 2 fields and setting them wherever was conveniennt10:29
jamfwereade: 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
fwereadejam, yeah, it was a *LastError as it happens10:29
jamfwereade: it feels like something that needs a bit more documentation so that we know why and someone doesn't just refactor the fixes away10:30
jamfwereade: assuming we don't have good ways of triggering those cases.10:30
fwereadejam, sgtm10:30
fwereadejam, if someone breaks it it will fail intermittently because we interact with the collections in map ordering10:30
fwereadejam, and they fail in all manner of excitingly different ways10:30
fwereadejam, so, yeah, I will add to the documentation10:31
jamfwereade: 2 page diffs make me sad...10:32
fwereadejam, me too :(10:32
jamfwereade: just grabbing a local copy and vim. at least I can jump around and search more easily10:33
jamI like inline comments, but navigation is hard10:33
fwereadejam, yeah, a lot of it is just that EnvironTag addition, but it obscures the meat10:33
jamyeah10:34
jamfwereade: I notice we don't explicitly create the txns.stash and txns.purge? (added by menno, IIRC).10:36
jamnot much with what you did, but just one of those "we create all the collections here" except the ones we don't.10:36
fwereadejam, I explicitly turned my head away from that rabbit hole10:36
fwereadejam, we create the same collections we did before and that's all I know10:37
fwereadejam, I *think* txns.log is the only important one10:37
jamtxns.stash is created by mgo10:37
fwereadejam, and quite possibly not even created explicitly?10:37
jamand txns.purge? was our bookkeeping page for when the last purge was run/how much it cleaned out/etc.10:37
jamfwereade: mgo/txn does a "C.database.name + ".stash") sort of trick.10:38
jamcreated under the covers.10:38
fwereadejam, it would indeed be good to add those as rawAccess collections just to make it clear that they shouldn't be touched10:38
fwereadejam, yeah, indeed10:38
jamfwereade: a thought… what about changing the comment strings in allcollections.go into string attributes on the collectionInfo structs?10:40
fwereadejam, I wanted to do that and then couldn't quite convince myself it was that useful10:41
fwereadejam, so I like the idea, but can you explain why? ;)10:41
jamfwereade: large lists of metainformation feels like something you could use to automate documentation about said information10:42
jamharder to scrape comments than write a "for foo in collections" sort of loop10:42
jambut someone would actually have to write that part10:42
fwereadejam, I counter "YAGNI", but I like the idea enough I think I'll do it ;p10:42
jamfwereade: I can certainly see people asking "what is the layout here" and we can just point them at allcollections.go10:43
jamit *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
fwereadejam, yeah, just putting that information together feels like the big winn10:43
jamat which time they could turnt hem into strings10:43
jamfwereade: ugh.. leaseC vs leasesC being multi-aware vs not.10:44
jam+2 on deprecating that ASAP. single-character typos having bad consequences10:44
fwereadejam, I just started the branch to tear that out by the roots :)10:44
fwereadejam, 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 up10:45
fwereadejam, at the very least I'll change its name to doNotUseThisDeprecatedLeaseC10:46
jamthisIsNotTheLeaseYoureLookingForC10:46
fwereade:D10:46
jamfwereade: so ATM we have no raw-access collections, just a place to put them?10:49
fwereadejam, yeah10:50
fwereadejam, have agreed with wallyworld that status-history in particular wants to go there10:50
fwereadejam, thought I'd prepare the ground since I was there ;)10:50
jamfwereade: 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:52
fwereadejam, perhaps, but (1) I'm not sure entirely sure where we'd use them and (2) I'm not certain that that organisation is fundamental10:54
fwereadejam, the thing that's scratching at the back of my mind is that we use several databases anyway10:55
fwereadejam, and collectionSchema is only a step in a hopefully-good direction10:55
fwereadejam, it doesn't cover everything yet and baking in *too* much structure might not be ideal10:55
jamfwereade: 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:56
fwereadejam, the rawAccess attribute is the only thing that controls that -- and, yeah, it's the multiEnvRunner that pays attention to it10:57
fwereadejam, and there's an empty branch in envStateCollection for somehow preventing .Writeable() access to non-raw-access collections10:58
fwereadejam, but that's not done mainly because we still have no shortage of direct .Writeable access to non-raw collections10:59
fwereadejam, (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
fwereadejam, (concur? don't have time to do anything about it, just thinking aloud)11:02
jamfwereade: I haven't specifically dug into it, but from your description it definitely sounds like a leaky abstraction11:03
jamand a case for "I read this ID and I pass it back in and read it back again" and they don't all agree11:03
fwereademenn0, hey, in case you're awake, did we take Settings into account when we did the multi-env stuff?11:03
fwereadejam, yeah11:04
fwereademenn0, hooray, we did11:04
menn0fwereade: I was pretty sure we did11:05
* menn0 not working, honestly11:05
menn0:)11:05
fwereademenn0, 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 more11:06
fwereademenn0, and I'm not 100% sure how that would play out in practice, but I'm pretty sure it would be no fun11:07
fwereademenn0, 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
fwereademenn0, anyway, you are not working, I will stop talking ;p11:08
menn0fwereade: i'm working a little kinda... while also making soup and doing some non-work jobs11:08
* fwereade knows how that goes :)11:09
* fwereade is not expecting anything resembling snappy repartee11:09
* fwereade coffee actually11:09
menn0fwereade: just getting a windows hyperV VM set up to do windows builds and test runs11:09
menn0fwereade: thinking about the possibility of a name collison on "env-uuid"11:12
menn0fwereade: it seems most likely for settings11:12
mgzer, what is theis failure trying to tell me? http://paste.ubuntu.com/1183035211:12
menn0fwereade: almost everywhere else we have a struct which will already have env-uuid on it11:13
menn0fwereade: and it'll be fairly obvious what it's for11:13
menn0fwereade: maybe for settings there should be a check to block exernal uses of env-uuid, txn-revno etc ?11:14
menn0mgz: the HasLen failures are a little hard to read...11:14
menn0mgz: it's showing you that it got an empty slice of *syslog.Writer but it expected a length of 211:15
mgzmenn0: aha, thanks11:15
menn0mgz: the obtained line is showing you the full actual thing that was obtained11:16
menn0mgz: not very clear though11:16
mgzmenn0: have a TestPrunes failure on ggco, do you want me to reopen bug 1459291 or open a new bug?11:19
menn0mgz: can you pastebin the output for me?11:20
mgzmenn0: http://reports.vapour.ws/releases/2858/jub/run-unit-tests-trusty-ppc64el/attempt/349011:21
menn0mgz: that gives me a 404 (and I am logged in)11:22
mgzs/jub/job/11:23
mgzsorry, I have irc on a different machine and it makes passing links around dodgy :)11:23
menn0mgz: aww but I wanted to see the jub :)11:26
mgzehehe11:26
menn0mgz: regarding the problem... pls create a new bug11:26
mgzokay.11:26
menn0mgz: I've seen this before and could have sworn I had already created a ticket11:27
menn0mgz: ah, no, there it is in my personal todo list11:27
menn0mgz: pls assign the bug to me11:27
mgzmenn0: done, bug 147177011:32
mupBug #1471770: TestPrunes fails occasionally still <ci> <intermittent-failure> <test-failure> <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1471770>11:32
menn0mgz: tyvm11:34
mgzmenn0: both failures I have since your fix are on the ppc64 tests11:35
* fwereade ended up having lunch too11:39
fwereademenn0, fwiw, what we should do is put the actual settings in a subdocument, and just makie sure we escape the keys properly11:39
perrito666morning11:40
menn0fwereade: that would work nicely too11:40
menn0and has the added benefit of not limiting the keys so much11:41
fwereademenn0, it's always just been one of those copious-free-time bugs :/11:41
menn0fwereade: would lookups be slower in a subdocument? you don't get the default index on _id then right?11:42
fwereademenn0, surely _id would jsut stay at the top level with the others11:42
fwereademenn0, I'm not sure we'd need to index settings by content?11:42
menn0fwereade: 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 much11:43
fwereademenn0, it's just a document with everything jammed into the top level alongside the metadata :/11:44
fwereademenn0, it was a useful type in python, against zookeeper11:44
fwereademenn0, as we switched languages and backends it gradually made less sense but was always basically just a straight port11:45
mupBug #1471770 opened: TestPrunes fails occasionally still <ci> <intermittent-failure> <test-failure> <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1471770>11:48
mupBug #1471771 opened: After "juju destroy-service <charm-name>" is executed,  the corresponding Windows charm service is not uninstalled <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1471771>11:48
menn0fwereade: ok, right so there's a doc per env11:48
menn0fwereade: so a subdocument would be fine11:49
fwereademenn0, settingsC has *so much* in it11:49
menn0fwereade: a smaller, but grosser, change would be to translate the sensitive field names into other ones for storage11:50
fwereademenn0, 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 of11:50
menn0fwereade: that is a lot11:50
menn0fwereade: any danger of hitting the 16MB limit?11:51
fwereademenn0, oh!11:51
fwereademenn0, no, each of those things is its own N documents11:51
fwereademenn0, the collection holds a lot, so a lot of things are affected, is my only point11:51
menn0fwereade: ok so not one doc per env11:51
menn0fwereade: that's not so bad then11:52
* menn0 should stop discussing this subject when he hasn't looked at the code11:52
fwereademenn0, 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
fwereademenn0, sleep well, thanks for the conversation11:52
menn0fwereade: no worries. i don't think I contributed anything useful :)11:53
=== psivaa is now known as psivaa-afk
fwereadeperrito666, apiserver/common/getstatus.go:16312:07
fwereadeperrito666, it looks like the query is a list of unit tags but it tells us information about some other entity12:08
fwereadeperrito666, if we want to know service status, why are we not passing service tags?12:08
mupBug #1471775 opened: TestModeForwarding occasionally fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1471775>12:09
dooferladvoidspace, TheMue: Review please: http://reviews.vapour.ws/r/210512:13
TheMuedooferlad: ok12:13
perrito666fwereade: iirc, implements StatusGetter12:15
fwereadeperrito666, right, that just means it accepts a list of entities annd will tell yuo their status, assuming you're properly authed12:15
fwereadeperrito666, why does it accept a list of entities and tell you the statuses of some *other* enntities?12:15
voidspacedooferlad: looking12:16
perrito666fwereade: oh?12:16
* perrito666 put on glasses12:16
fwereadesorry brb kee ptalking12:18
perrito666fwereade: 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:24
voidspacedooferlad: "return None" is slightly confusing :-)12:25
voidspacedooferlad: just to my Python addled brain...12:25
voidspacedooferlad: one comment so far12:25
TheMuedooferlad: and added another one ;)12:29
fwereadeperrito666, the question is -- why do we expect service status to come back when we ask for unit status?12:30
fwereadeperrito666, it's fine to restrict auth to the leader unit12:30
fwereadeperrito666, but that's a property of the connection, not of the request12:31
fwereadeperrito666, we already know who's connecting, and can use that information to decide whether or not to give out information about X entity12:31
fwereadeperrito666, but this *doesn't* implement StatusGetter12:31
fwereadeperrito666, because StatusGetter is supposed to tell you the status of the thing you asked for12:32
perrito666nope, it implements ServiceStatusGetter12:32
perrito666I am now reading the rest of the code12:32
fwereadeperrito666, ...we already had a StatusGetter12:33
fwereadeperrito666, it only handed out unit statuses, because those were all that existed12:33
fwereadeperrito666, whether or not to hand out service statuses is purely an auth-level problem12:34
fwereadeperrito666, the StatusGetter is not a *Unit*StatusGetter12:34
fwereadeperrito666, it just accepts entities and returns their statuses12:35
fwereadeperrito666, if they have them, and if the current user is authorized to know whether they even exist12:35
fwereadeperrito666, make sense?12:36
perrito666fwereade: not really, I feel like entering in a mid sentence conversation here12:37
* perrito666 goes and re reads the whole file to make sure we are talking about the same here12:37
fwereadeperrito666, heh, context is removing juju/juju/lease and seeing what failed12:38
fwereadeperrito666, getstatus.go was the second one; reading it, I got confused, and am not seeking understanding12:40
fwereades/not/now/12:40
perrito666quick hangout?12:43
perrito666I have 15 mins before my next meeting12:44
perrito666(but you are not allowed to laugh on my winter clothing)12:44
fwereadeperrito666, sure12:44
fwereadeperrito666, would you start one please?12:45
perrito666sure hold a sec12:45
fwereadeperrito666, actually 2 mins coffee refill12:46
perrito666k12:46
perrito666fwereade: https://plus.google.com/hangouts/_/gzh5yzfc4533ewopliwwbc62wya?hl=en12:48
TheMuedooferlad: commented your question13:42
dooferladTheMue: diff updated14:13
TheMuedooferlad: already pushed? cannot see it14:17
dooferladTheMue: doh! wrong branch. One moment.14:18
TheMue*lol*14:18
=== kadams54 is now known as kadams54-away
TheMuedooferlad: voidspace: hangout16:01
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
=== liam_ is now known as Guest20028
perrito666fwereade: ping18:11
mupBug #1471242 changed: juju upgrade-juju to 1.24.2 fails with "invalid series: wily" <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1471242>18:55
mupBug #1471936 opened: suite.TestRunCmd shows script failure <intermittent-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core feature-proc-mgmt:Triaged> <https://launchpad.net/bugs/1471936>18:55
mupBug #1471941 opened: widows unit tests fail because handles are not avIlable <intermittent-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1471941>18:55
mupBug #1470714 changed: Ubuntu downloads are non-obvious <juju-core:Fix Released> <https://launchpad.net/bugs/1470714>22:23
=== kadams54 is now known as kadams54-away
mupBug #1470876 changed: Deploy --to zone=<name> <add-unit> <deploy> <feature> <landscape> <placement> <juju-core:Triaged> <https://launchpad.net/bugs/1470876>22:50
mupBug #1472004 opened: agent-state error yet unit logs show no error <juju-core:New> <https://launchpad.net/bugs/1472004>22:50
mupBug #1472009 opened: manual provisioning with juju requires systemd-services <juju-core:New> <https://launchpad.net/bugs/1472009>23:20
mupBug #1472014 opened: juju 1.24.0: wget cert issues causing failure to create containers on 14.04.2 with lxc 1.07 <openstack-installer> <juju-core:New> <https://launchpad.net/bugs/1472014>23:20
perrito666wallyworld: anastasiamac I completely blanked out23:20
=== jog_ is now known as jog
wallyworldperrito666: we are in standup if you want to join :-)23:23
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
wallyworldfwereade: i will hang around in our standup hangout in case you do join23:46
=== kadams54 is now known as kadams54-away

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!