=== axw_ is now known as axw [01:16] wallyworld: do you want to take another look at https://codereview.appspot.com/59560043/ before I land? [01:17] I removed the things you and rogpeppe objected to [01:17] ok, i trust you :-) [01:17] cool [01:30] waigani: standup? [01:31] yep === axw_ is now known as axw [06:14] I just had to put my laptop in the fridge! Ubuntu on macbook, woke from sleep by itself while in its cover. When I pulled it out, it was almost too hot to hold! [06:19] axw_: sorry, wrong channel [06:19] ok [06:19] nps [06:20] axw_: i should put PerformUpgrade in the new file too? [06:20] wallyworld: that's not going to change over time is it? [06:20] probs not, ok just the upgradeops then [06:23] wallyworld: your 1.16 branch seems to include things other than dependencies.tsv [06:23] not intentional, right? [06:26] axw_: lbox fucked up [06:26] it didn't choose the correct branch [06:27] i just deleted the siteveld version and pushed manually [06:27] ok [06:27] https://code.launchpad.net/~wallyworld/juju-core/gwacl-231/+merge/205698 [06:27] ah I see [06:27] ta [06:27] i think that's all we need for 16.6 [06:31] * wallyworld soccer, be back later [06:59] axw_, ping.. looking at revno 2204 and trying to understand why juju is opening/reading all of a user's ssh keys [06:59] hazmat: hey, just a moment, refreshing memory [07:00] hazmat: all of the files in ~/.juju/ssh [07:00] not in ~/.ssh [07:01] ~/.juju/ssh contains an auto-generated key-pair for Windows/people without keys [07:01] and you can dump whatever other key pairs you want Juju to try in there [07:01] and then Juju will add "-i " for each valid private key in there to each invocation of ssh [07:03] axw_, ic.... i'm trying to track down where juju is reading all the ssh files in my ~/.ssh .. one of my keys is very old and i'm getting a looped failure in logs for authenticationworker [07:03] running juju get-env does indeed show a concat of all my pub keys as the default env setting [07:03] runner.go:220 worker: exited "authenticationworker": adding current Juju keys to ssh authorised keys: generating key fingerprint: invalid authorized_key" [07:05] hazmat: ah right. authorized-keys defaults to the default public keys in ~/.ssh [07:05] hazmat: in environs/config [07:05] authkeys.go I think [07:05] hazmat: do you have an SSH v1 public key? [07:06] could just be a bad format in one key, but that also implies non validation up front which leads to env failure during usage.. but more just curious why the default to all, there's a list of known keys in the src. [07:06] axw_, it looks that way re v1.. dunno, the key is pretty ancient (10+ yrs) [07:07] yeah it probably should validate earlier. sorry, not parsing the last sentence. what do you mean defaulting to all? [07:07] it will pick up ~/.ssh/id_rsa.pub, ~/.ssh/id_dsa.pub, ~/.ssh/identity.pub [07:08] axw_, yeah.. that's probably it.. 5 keys total in the env [07:09] 2 sys keys, plus the probes on the rest.. previous behavior with the list was just to use the first one that was found, it looks like its appending all of them here. [07:10] yup [07:10] has been like that as far as I remember, but I don't go back to pyjuju :) [07:11] fair enough, not many do, and the rest try to forget :-) [07:11] heh [07:13] so the corner case bug is basically to validate default key before setting value, else auth worker dies in a loop. [07:14] axw_, incidentally fwereade came up with a decent solution re initialization with manual provider client plugin, copy JUJU_HOME to temp, bootstrap, copy jenv file back [07:14] yes I think so. we should just ignore public keys that are invalid [07:15] cool :) [07:15] by solution i mean workable hack :-) [07:48] does anyone have a cute picture of the juju-core source import graph? [07:56] waigani: ^^ did you manage to create one? [07:58] axw_: no, it was deemed a distraction from bug hunting - so I abandoned it [07:58] ah yeh [07:58] ok [08:00] but these are some of the d3 graphs that caught my eye: [08:00] http://www.findtheconversation.com/concept-map, http://bl.ocks.org/robschmuecker/7880033, http://mbostock.github.io/d3/talk/20111116/bundle.html, http://bl.ocks.org/mbostock/4063550 [08:06] I was looking into getting output from libraries like pprof and pythia that I could pump into a d3, taking the about as inspiration/starting point [08:06] *above [08:20] nm :) [08:23] jamespage: https://code.google.com/p/go/issues/detail?id=7303 btw === mwhudson is now known as zz_mwhudson [10:32] wallyworld, +1 for shiteveld :) [10:32] yeah :-) [10:45] rogpeppe1, mgz, wallyworld, natefinch, standup? [11:07] dimitern: the apt-get flag is --target-release [11:07] but how that works with non-release things like ppas I'm not actually sure [11:08] and general priorities can be handled by apt/preferences and Pin-Priority [11:08] what's the question? I think I missed it (have been struggling with getting ppas working in trusty since no one has released trusty-compatible ppas yet) [11:09] mgz, cheers [11:11] natefinch, the question is how to install our juju packages from the cloud pocket, without screwing up charms that need different versions of packages that happen to be in the cloud pocket (i.e. django) [11:11] dimitern: ahh, I see [11:12] jamespage, are you around? [11:14] jamespage, you've commented on bug 1240667 about pinning the cloud-archive pocket at a lower priority (400) than the main archive, what's the default priority otherwise? [11:14] <_mup_> Bug #1240667: Version of django in cloud-tools conflicts with horizon:grizzly

[11:16] jamespage, and also, having done that during cloudinit, what --target-release should we use in apt-get install to ensure we get cloud-archive packages? "precise-updates/cloud-tools" ? [11:17] smoser, perhaps you can help there? ^^ [13:04] dimitern, reading [13:04] dimitern, default priority is normally 500 I think [13:05] jamespage, ah, ok [13:05] jamespage, and what --target-release should I give to apt-get ? [13:05] dimitern, just checking that now [13:08] looking that the Release file I think its: [13:08] Codename: precise-updates/havana [13:08] dimitern, ^^ [13:08] well not that one [13:08] jamespage, precise-updates/cloud-tools perhaps? [13:08] checking again [13:09] dimitern, precise-updates/cloud-tools looks right [13:09] jamespage, and what if it's not precise, but something else? [13:09] dimitern, well for at least the next 9 months its always precise [13:09] cloud-tools does not support any other ubuntu series [13:09] jamespage, ah, I see [13:10] jamespage, thanks! [13:10] np === rogpeppe1 is now known as rogpeppe [14:15] hi all, will someone please review this and address jamespage's concerns? thanks! https://code.launchpad.net/~teknico/charms/precise/keystone/add-valid-service/+merge/205171 [14:33] dimitern: just checking, because i sent it with my non-canonical email, but i haven't seen a bounce, and i see it in the archives, have you seen my latest post to juju-dev (starting "I think that the best way to see how they look in real code") ? [14:33] well, that was a fun power cut [14:33] power cuts are always fun [14:34] rogpeppe1, let me check [14:34] rogpeppe1, yep [14:34] dimitern: ok, cool. i guess someone must have subscribed me at my gmail address [16:04] abentley, rogpeppe1 Can I trouble both of you to join a hangout to discuss releasing 1.16.6 [16:04] sinzui: sure [16:05] sinzui: certainly. [16:05] abentley, rogpeppe1 https://plus.google.com/hangouts/_/76cpidk53plj3t5324gml118j0?hl=en [16:08] rogpeppe1, could you give me a shout when you're done in the hangout - I have a small favour to ask [16:10] sinzui: one think I'll note, is there have been requests to backport the network fix if we don't get a 1.18 out in like, the next week or so [16:10] (we really should) [16:52] rogpeppe1, natefinch, mgz, a small review that fixes bug 1240667 ? https://codereview.appspot.com/61410051 [16:52] <_mup_> Bug #1240667: Version of django in cloud-tools conflicts with horizon:grizzly

[16:53] dimitern: On It [16:53] mgz, cheers! [16:54] description sounds right on [17:02] dimitern: looking [17:05] dimitern: reviewed, lets poke smoser to check it as well. [17:05] mgz, thanks [17:05] rogpeppe1, ^^ [17:06] smoser or jamespage - can you take a look at this fix for the cloud-tools bug? https://codereview.appspot.com/61410051 [17:24] mgz, i agree on the dodgy ness. [17:24] :-( [17:25] i'm actually surprised that would work. [17:25] cause as i read it you're sending one argument that is: [17:25] --target-release 'precise/cloud-tools' [17:25] which i would have thought apt would balk at [17:26] https://codereview.appspot.com/61410051/diff/1/cloudinit/options.go looks sane [17:29] any other cunning ideas scott? [17:29] am i right in reading that ? [17:29] essentially you're doing: 'apt-get' 'install' ... "--taget-release 'precise/cloud-tools' 'mongodb'" [17:29] ? [17:30] or something to that effect? [17:30] so 2 thoughts [17:30] something like that, the yaml quoting rules makes it all very fun to parse [17:30] but cloud-init should do the right thing and get that all passed "correctly" to apt [17:30] ie, not passing it through 'sh' [17:30] hm.. [17:31] oh well. [17:31] so 2 thoughts [17:31] dimitern: in your ec2 test, did you look at the apt logs? [17:31] a.) we could separate juju into its own cloud-archive. i don't really like this, and its a lot of work, but then that archive wouldnt have the other packages that were screwing things up (the ones that maas has brought in). [17:31] that may or may not fix things. [17:32] dimitern: reviewed [17:32] b.) you could just add the archive andinstall something from it later (not through cloud-init). [17:32] ie, charms install stuff all the time, and could handle that outside cloud-init. [17:33] we could probbly do the mongo install as a seperate run_cmd [17:33] but that has plusses and minuses as well [17:33] we'd need to re-add all the nice extra args to deal with unattended apt, and it's at a later stage in the boot [17:44] rogpeppe1, ta! [17:44] mgz, not apt logs, just cloud-init-output log [17:45] and everything worked nicely [17:48] smoser, what I changed is instead of apt-get [numerous options] install 'package', for the packages with --target-release it generates the same apt-get [opts] install --target-release 'precise-updates/cloud-tools' 'package' [17:49] mgz, well, you would have to do that (the extra args), i agree. [17:49] thats less than ideal, but it is something that really doesn't change. [17:49] another thing you'd not get "for free" is eatmydata usage by cloud-init. [18:44] * rogpeppe1 is done [18:44] g'night all [18:45] night rog === zz_mwhudson is now known as mwhudson [21:28] o/ waigani wallyworld_ [21:30] thumper: hi [21:31] lots of emails to get through i assume [21:31] wallyworld_: I have a doctors appt shortly, but will be back later [21:31] ok [21:31] wallyworld_: quite a bit, but currently going through the upgrade doc [21:31] talk then [21:31] ah yes [21:31] just trying to address a few comments [21:32] we can discuss when you get back [21:32] * thumper nods [21:32] * thumper tries to calculate time to the dr's office === thumper is now known as thumper-afk === thumper-afk is now known as thumper [22:26] wallyworld_, thumper do either of you have a moment to review a branch? https://codereview.appspot.com/61980043 [22:27] yep [22:27] done [22:30] sinzui: all good for 16.6 then i assume? [22:31] wallyworld_, yes, thank you very much! [22:32] great :-) [22:32] wallyworld_, I have released. I am waiting for Ubuntu packaging and backporting. That might be 12 hours away [22:32] ok [23:42] thumper: did you want a catchup before the standup? to align on upgrades etc [23:42] wallyworld_: yes, we also have our normal weekly call [23:42] that's tomorrow [23:43] but we can hangout now [23:43] crap, so it is [23:43] * thumper is eating [23:43] ok [23:43] how about in a while? [23:43] but yes [23:43] do want to chat [23:43] sure, i'll wait with baited breath [23:46] sinzui: are the compatibility bugs you refer to in your email the 2 azure bugs listed on 1.17.3 milestones? [23:46] are there any others? [23:47] there are still many listed on https://launchpad.net/juju-core/+milestone/1.18.0 [23:47] ah yes :-( [23:48] i'd personally like to see these all fixed asap so we have the option of releasing a 1.18 when needed [23:49] I will create a compatibility tag. oh, each is really a regression. I will track these as regressions [23:49] in an ideal world regressions would be critical [23:49] the opportunity cost of not being able to release 1.18 when needed (eg when the havana stuff lands) is large [23:54] surely bug 1262175 isn't a bug as it is stated [23:54] <_mup_> Bug #1262175: debate drop --upload-tools flag

[23:54] debate something? [23:54] geez [23:55] * thumper goes to make a coffee prior to wallyworld_ cat [23:55] chat [23:57] thumper: i like white with none