[00:04] wallyworld, thumper, katco or axw : fix for bug 1451674: http://reviews.vapour.ws/r/1581/ [00:04] Bug #1451674: Broken DB field ordering when upgrading to Juju compiled with Go 1.3+

[00:06] menn0: looking [00:13] wallyworld: ta [00:14] wallyworld: just saw one thing... addBsonDField could do with a docstring [00:14] sure [00:18] menn0: haven't finished reading it, but there's a but i can see in updateBsonField [00:19] well i think it's a bug [00:19] wallyworld: ok? [00:19] the loop var "field" is being updated, but needs to be assigned back into the slice [00:19] otherwise the bson.D slice passed in will remain unmodified [00:20] wallyworld: no I think that ok b/c the slice isn't being modified, just a field of a struct inside it [00:20] that's what i mean [00:20] the field loop var is a copy of the slice value [00:20] wallyworld: if that didn't work then most of the upgrade unit tests would be failing but they still all pass [00:21] menn0: http://play.golang.org/p/P3bI04FsF9 [00:21] if i comment out // this line it prints the same slice [00:22] wallyworld: hmmm ok. i wonder why everything still works then. [00:22] nfi [00:22] i hadn't finished reading it yet :-) [00:22] i'll keep reading to see if i can see why [00:27] wallyworld: no idea why it's working but I'll change it just to be sure [00:28] menn0: ok, do you agree there's an issue? or am i on crack? [00:28] wallyworld: your example is pretty convincing [00:28] wallyworld: so I'm going to fix it [00:28] ok, would be good to understand why [00:30] wallyworld: yeah there could be a wider test problem [00:30] wallyworld: i'll look at that too [00:30] wallyworld: lunch first [00:30] that's what i'm afraid of [00:30] * wallyworld is hungry too [00:31] * anastasiamac wonders why wallyworld is afraid of lunch [00:33] Bug #1452082 was opened: restore: agent old password not found in configuration

[00:34] wallyworld: this is probably nicer (and faster) than copying: http://play.golang.org/p/v4b16JDzOE [00:36] menn0: that works. i still fear the test may be faulty. but have a mouthful of food so will look ina bit [00:43] menn0, wallyworld: this is what I get: http://pastebin.ubuntu.com/10993413/ === kadams54-away is now known as kadams54 [00:45] right, so there's a bug there. but also in the test because it didn't fail [00:46] wallyworld: yep, I said as much in my review [01:10] menn0: noted [01:10] let me check, that is confusing [01:16] waigani: can I get a review? http://reviews.vapour.ws/r/1579/ [01:17] natefinch: yep. Just let me get some lunch and yours is next on the list [01:17] waigani: cool, thanks [01:18] natefinch: LGTM [01:19] davecheney: thanks [01:23] waigani, wallyworld : I definitely agree that that func needs to be changed. I'm going to figure out why the tests pass despite it. [01:23] ty, sounds good [01:30] wallyworld: I see why the everything still works [01:30] waigani: ^^^ [01:30] updateBsonDField is only used to update _id [01:30] and the correct _id is used on the txn.Op [01:30] this override the value on the document (in fact you can leave _id off documents, it gets automagically added) [01:30] wallyworld, waigani: i'll fix it anyway of course [01:31] menn0: ah makes sense, glad you found it [01:36] davecheney: exact same thing, except against 1.24, where it should have been targeted in the first place: http://reviews.vapour.ws/r/1582/ [01:42] * davecheney looks [01:44] (produced by cherry picking from the first PR, ignoring the two merge commits that prevent me from just re-PRing from the same branch... stupid merges) [01:45] Bug #1442132 changed: [packaging juju-1.23] Issues met while working on debian/copyright file

[01:45] Bug #1445063 changed: addressable containers cannot resolve non-FQDN in maas

[01:45]

[01:45] Bug #1446662 changed: Vivid bootstrap and destroy-environment intermittently fails

[01:45] Bug #1446857 changed: MeterStatusWatcher tests fail on windows test slave

[01:45] Bug #1447595 changed: TestLeadership fails on windows test slave

[01:45] Bug #1447853 changed: Local charms are not added to storage on upgrade to 1.22.x

[01:45]

[01:47] waigani, wallyworld: PR updated as per review comments: http://reviews.vapour.ws/r/1581/ [01:48] wallyworld, axw Do either of you have a moment to review http://reviews.vapour.ws/r/1583/ [01:49] sinzui: done [01:49] thank you axw [01:50] axw: time for a quick chat in standup? [01:50] menn0: will look in a sec [01:50] wallyworld: sure, brt [01:52] voidspace: ping ? [01:55] davecheney: is after midnight for voidspace, unlikely to be around [01:55] and he isn't on line even [01:58] i'll wait [01:59] https://www.youtube.com/watch?v=UJkxFhFRFDA [01:59] davecheney: while you wait can you review that second PR? ;) === kadams54 is now known as kadams54-away [02:01] davecheney: https://www.youtube.com/watch?v=6g4dkBF5anU [02:06] menn0: i might be retarded driving reviewboard, but i can't get a old-new diff to show the test changes; the test was updated i assume [02:06] wallyworld: no, the tests were fine b/c the end result was correct [02:07] hmm, ok. it worried me that the test passed even though the code was flawed [02:07] wallyworld: but by side effect [02:08] i'm still a little hestitant [02:08] when a key function in the solution doesn't work and the test still passes.... [02:08] wallyworld: as I explained updateBsonDField was only used in one place and in that case it didn't really matter what updateBsonDField did b/c mgo or mongo prefers the key from the txn.Op over the document [02:08] wallyworld: may I should just remove updateBsonDField and the call to it [02:09] wallyworld: but then we're relying on an effect of mgo or mongo [02:09] if we don't need it then yeah [02:09] wallyworld: which I guess is very unlikely to change [02:09] menn0: or test the func explicitly [02:09] i'm -1 on keeping unecessary code around [02:09] wallyworld, waigani: i'm going to remove it === kadams54-away is now known as kadams54 [02:10] there's plenty of other places in juju that use the txn key [02:10] so if mgo changes, juju will break badly [02:10] maybe remove the method and add a decent comment [02:11] it's vcs. We can go back in time to get the code if we need it again. [02:12] wallyworld: Any specific it reason to mark this bug high, other than it makes us look like knuckleheads? https://bugs.launchpad.net/juju-core/+bug/1370896 [02:12] Bug #1370896: juju 1.21-alpha1 has conf files in /var/log/juju on instances

[02:13] natefinch: that, plus a user has a reasonable expectation to blow away a log dir and not break things [02:13] wallyworld: yeah, that's a good point [02:14] i can imagine sysadmins doing that regularly to reclaim space etc [02:14] wallyworld anastasiamac: if you have any time today, would appreciate if you could look over https://github.com/juju/docs/pull/411 and see if we're missing anything important [02:15] wallyworld: done [02:15] will do [02:15] menn0: ty, lookng [02:15] axw: looking :D [02:16] wallyworld: the rest of our config files are under /var/lib/juju/, is that a fair place to put them? The bug mentions /etc/ but AFAIK we don't store anything there right now [02:17] natefinch: IMO, /var/lib/juju is reasonable. longer term perhaps we should put stuff in /etc/juju or wherever [02:17] not sure [02:17] wallyworld: thanks [02:17] np, thanks for finding and fixing [02:18] wallyworld, waigani: thanks both for your thorough reviews [02:18] Bug #1326091 changed: deploying into kvm with local provider, hostnames are not unique

[02:18] Bug #1326799 changed: juju should log at environment URL

[02:18] Bug #1436925 changed: juju status complains "config has no UUID" when no .jenv is present

[02:18] Bug #1437015 changed: debug-log spammed with leader-election messages

[02:18] Bug #1438489 changed: juju stop responding after juju-upgrade

[02:18] Bug #1446608 changed: agent panic on MAAS network with uppercase characters

[02:18] Bug #1447841 changed: eu-central-1 AWS region V4 signing required and not supported

[02:18] Bug #1449302 changed: upgrades: old machines need block devices document

[02:18] Bug #1449367 changed: remove storage feature flag

[02:18] Bug #1449436 changed: Environment variables are not propagated to jujud on vivid

[02:18] Bug #1450146 changed: vsphere provider feature flag should apply only to bootstrap

[02:18] Bug #1451297 changed: Upgrade from 1.18 to 1.23 fails: password for machine agent can't be set

[02:19] menn0: I was off target, but glad it helped [02:19] thumper: your opinion? our rsyslog config files are under /var/log/juju/ right now.. is /var/lib/juju/ a suitable fix, or should we start using /etc/juju/? re: https://bugs.launchpad.net/juju-core/+bug/1370896 [02:19] Bug #1370896: juju 1.21-alpha1 has conf files in /var/log/juju on instances

[02:20] man that's a lot of mupping [02:20] mupping hell! [02:20] yeah, mup is pretty muppy tonight [02:20] hehe [02:20] natefinch: I'm trying to get context [02:20] axw: anastasiamac: btw one thing we should do after feedback from william is to incude "naked" provider types in the pools list - they will appear as pools with empty config [02:21] natefinch: hmm... [02:21] wallyworld: agreed [02:21] personally I think we should start using /etc/juju [02:21] thumper: yeah, i think that's ok for longer term, but for 1.24..... [02:21] natefinch: in the near future, we'll have additional acceptable certs [02:21] /etc/juju/certs.d/ [02:21] we should do this holistically [02:22] are we expected for fix this for 1.24? [02:22] if so... just use $datadir [02:22] yes, it's on the 1.24 list [02:22] which is /var/lib/juju [02:22] stakeholder bug [02:22] and we'll move to /etc/juju Real Soon Now™ [02:22] +1 [02:22] heh ok, cool [02:23] thanks thumper [02:25] (and wallyworld) [02:25] sure [02:25] thanks for fixing [02:26] axw: added my 2c to 411 :D tyvm for keeping docs uptodate!!!! :)) [02:27] anastasiamac: thanks === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [03:40] hows it going everyone?? [03:40] Can anyone give a few examples for possible values for the flat-network-providers config for quantum-gateway? [03:46] bdx: we're mostly core juju devs on this list. The intricacies of specific charms are not really our specialty. [03:47] bdx: I think most of the charm developers are in US/UK time zones, and so probably not online right now [03:48] bdx: I recommend sending an email to juju@lists.ubuntu.com with your question, that way you can get answers asynchronously. [04:20] natefinch: Thanks! [04:35] is it possible to have a subordinate relate to another subordinate? it doesn't seem to actual cause the relationship to happen, so I'm guessing not. [04:51] Bug #1452113 was opened: log files are lost when agents are restarted under systemd

[04:51] Bug #1452114 was opened: Unnecessary errors emitted during init system discovery

[05:04] Bug #1452113 changed: log files are lost when agents are restarted under systemd

[05:04] Bug #1452114 changed: Unnecessary errors emitted during init system discovery

[05:10] Bug #1452113 was opened: log files are lost when agents are restarted under systemd

[05:10] Bug #1452114 was opened: Unnecessary errors emitted during init system discovery

=== urulama_ is now known as urulama [05:30] wallyworld: I've started looking into placement+storage. let me know if you think something else is more important [06:43] axw: placement + storage sounds great [07:53] wallyworld: there's a race condition in my storage hook order thingy, it's a bit borken :/ [07:54] oh noes [07:54] if the storage isn't provisioned fast enough, no hooks run [07:54] (for storage-using charms only) [07:54] we will be releasing a new build in a couple of days [07:54] ok [07:55] I'll switch over to fixing this [07:55] + [07:55] 1 [07:55] I've got half way through getting placement working [08:26] what's the easiest way of determining the mac address of a container deployed on a machine? [08:27] juju ssh I guess [08:31] voidspace: from outside or an agent running inside the container? [08:31] TheMue: from outside [08:31] TheMue: but I've found it via "juju ssh" [08:31] TheMue: thanks [08:31] voidspace: ok [08:36] axw: i'm off to soccer, back later. i've got maas storage working and unit tested, just finishing test double work to allow end-end start instance to run [08:37] "working" != tested live yet [08:37] done according to spec [09:01] dooferlad: jam: standup? [09:01] omw [09:33] hello folks. What version of go are we building the juju binaries with? [09:51] gsamfira: 1.2 :D except for vivid 1.3 [10:16] Bug #1452207 was opened: worker/uniter: charm does not install properly if storage isn't provisioned before uniter starts

[11:25] Hi, hows it going all? [11:26] Would someone be kind enough to share what the difference is between data-port and ext-port for neutron-openvswitch charm? .... And possibly [11:27] an example of how different params could be used? [11:55] github is down at present, so I've disabled the lander [11:56] mgz_, finally figured out https://bugs.launchpad.net/juju-core/+bug/1413910 [11:56] Bug #1413910: 1.21-rc1: Ambiguous resolution of private-address

[11:56] \o/ [11:56] bdx, hello [11:56] data-port is for vlan and flat networking traffic (east/west) [11:56] ext-port is for north-south traffic when using neutron dvr [11:57] ehe, so it is asciibetical sorting related? [11:58] jamespage: also liam's bug 1435283 [11:58] Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment

[12:04] mgz_: just before you posted this they posted "finished emergency maintenance" [12:05] yup, I'll try re-enabling shortly [12:08] mgz_, I de-duped and commented on gnuoy's bug [12:09] jamespage: thanks, Dimiter is off this week but I will poke someone else to pick this up [12:10] jam: ^ any cunning ideas on sane network selection logic when we grow a new address? currently we do insane things. [12:46] mattyw: aha, you're ocr today [12:50] mattyw: so, I have two branches to land, but I actually want to add to pr2158 and want some advice [12:50] I think the provider should log the instance type and image type it has selected [12:51] any opinions on where I should put that? [12:51] I guess in StartInstance rather than in FindInstanceSpec [13:01] voidspace, TheMue: MAAS call? [13:02] dooferlad: in saphire? because I've got no calendar entry [13:02] TheMue: Oh, if you aren't on the invite, don't worry [13:03] dooferlad: ok, I don't worry [13:03] ;) [13:03] mgz_, sorry - was feeding my face [13:03]