[00:17] <bigjools> davecheney: seems like the azure provider is now basically blocked on a cloudinit sru to precise...
[00:18] <davecheney> bigjools: ok, i'm making a 1.14 branch
[00:18] <davecheney> we can backport fixes in there to get it working once cloudinit is done
[01:04] <axw> davecheney: https://bugs.launchpad.net/juju-core/+bug/1216770 is merged, I just forgot to update the bug
[01:04] <axw> it is in 1.13.3
[01:15] <davecheney> axw: no worries
[01:15] <davecheney> https://docs.google.com/a/canonical.com/document/d/1aEvcmxSJaj1i9zNjGy48yKF-SPlTFwW-NiKfoO_Ygo4/edit#heading=h.h7wry0fbg197
[01:15] <davecheney> ^ hint hint
[01:17] <axw> davecheney: updated
[01:17] <axw> feel free to edit
[01:19] <wallyworld> axw: hi, i had a test failure locally with the manual provisioning stuff - detectSeriesAndHardwareCharacteristics() because for some reason the bash that runs doesn't like my .shinit. i think we should ensure the bash that runs ignores all such files
[01:19] <axw> wallyworld: doh, thanks. I'll get onto it
[01:19] <wallyworld> np :-)
[01:20] <davecheney> axw: cool
[01:20] <davecheney> the builders are backed up
[01:20] <davecheney> i won't get the build til after lunch
[01:20] <davecheney> but we've tagged 1.13.3 now
[01:20] <davecheney> so feel free to wreck the build
[01:20] <wallyworld> axw: i had a quick look - using --noprofile or --norc didn't work; there must be another option to ensure .shinit is ignored. .shinit is more a sh thing i think
[01:21] <axw> wallyworld: k, thanks
[01:21] <axw> wallyworld: do you mean the unit tests were failing? or you were playing with it?
[01:22] <axw> ah the sshscript thing I guess...
[01:22] <wallyworld> axw: test failure. i ran the tests cause a merged trunk and there were api changes i needed to port into the new manual provisioning code.
[01:22] <wallyworld> i have a .shinit, the bit that failed was a mkdir, go figure
[01:24] <hazmat> davecheney, re slowness on cli.. how long does bootstrap take for you ? i'm consistently getting 2m plus
[01:24] <davecheney> lucky(~) % juju bootstrap -e us-west-1 -v
[01:24] <davecheney> 2013-09-02 01:24:23 INFO juju.provider.ec2 ec2.go:209 preparing environment "us-west-1"
[01:24] <davecheney> 2013-09-02 01:24:23 INFO juju.provider.ec2 ec2.go:187 opening environment "us-west-1"
[01:25] <davecheney> 2013-09-02 01:24:23 INFO juju.environs.tools tools.go:81 filtering tools by released version
[01:25] <davecheney> 2013-09-02 01:24:23 INFO juju.environs.tools tools.go:28 reading tools with major version 1
[01:25] <davecheney> 2013-09-02 01:24:23 INFO juju.environs.tools tools.go:36 filtering tools by series: precise
[01:25] <davecheney> 2013-09-02 01:24:28 INFO juju.environs.tools tools.go:43 falling back to public bucket
[01:25] <davecheney> 2013-09-02 01:24:29 INFO juju.environs.tools tools.go:92 picked newest version: 1.12.0
[01:25] <davecheney> 2013-09-02 01:24:38 INFO juju.environs.boostrap bootstrap.go:56 bootstrapping environment "us-west-1"
[01:25] <davecheney> 2013-09-02 01:24:38 INFO juju.environs.tools tools.go:28 reading tools with major version 1
[01:25] <davecheney> 2013-09-02 01:24:38 INFO juju.environs.tools tools.go:33 filtering tools by version: 1.12.0
[01:25] <davecheney> 2013-09-02 01:24:38 INFO juju.environs.tools tools.go:36 filtering tools by series: precise
[01:25] <davecheney> 2013-09-02 01:24:39 INFO juju.environs.tools tools.go:43 falling back to public bucket
[01:25] <davecheney> 2013-09-02 01:24:48 INFO juju.provider.ec2 ec2.go:426 started instance "i-24a95f7e"
[01:25] <davecheney> 2013-09-02 01:24:50 INFO juju supercommand.go:284 command finished
[01:25] <davecheney> that is from australia
[01:25] <davecheney> i suspect the growing number of tools we have in the public bucket is not helping
[01:25] <hazmat> wow
[01:26] <hazmat> thats a huge delta from what i see
[01:26] <davecheney> 2013-09-02 01:14:29 DEBUG juju state.go:159 waiting for DNS name(s) of state server instances [i-9b6cfffc]
[01:26] <hazmat> davecheney, yeah.. it would be nice to just have a latest pointer
[01:26] <davecheney> 2013-09-02 01:14:40 INFO juju.state open.go:68 opening state; mongo addresses: ["ec2-54-226-75-153.compute-1.amazonaws.com:37017"]; entity ""
[01:26] <davecheney> i have no idea what is happening in those 10 seconds
[01:26] <davecheney> oh, sorry
[01:26] <hazmat> so that's roughly 16s vs 25s
[01:26] <davecheney> that is getting the dns name from the provider
[01:26] <hazmat> yeah.. instance id -> ip addr
[01:27] <davecheney> it's ec2 being slow
[01:27] <davecheney> what can I say
[01:27] <hazmat> its still 75% of the runtime cost that can be saved with some trivial caching
[01:27] <hazmat> per the bug title
[01:28] <davecheney> lucky(~) % juju status -e us-west-1 -v
[01:28] <davecheney> 2013-09-02 01:28:26 INFO juju.provider.ec2 ec2.go:187 opening environment "us-west-1"
[01:28] <davecheney> 2013-09-02 01:28:29 INFO juju.state open.go:68 opening state; mongo addresses: ["ec2-54-219-20-209.us-west-1.compute.amazonaws.com:37017"]; entity ""
[01:28] <davecheney> 2013-09-02 01:28:30 INFO juju.state open.go:106 connection established
[01:28] <davecheney> environment: us-west-1
[01:28] <davecheney> machines:
[01:28] <davecheney>   "0":
[01:28] <davecheney>     agent-state: started
[01:29] <hazmat> pastebin pls
[01:29] <davecheney>     agent-version: 1.12.0
[01:29] <davecheney>     dns-name: ec2-54-219-20-209.us-west-1.compute.amazonaws.com
[01:29] <davecheney>     instance-id: i-24a95f7e
[01:29] <davecheney>     instance-state: running
[01:29] <davecheney>     series: precise
[01:29] <davecheney>     hardware: arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M
[01:29] <davecheney> services: {}
[01:29] <davecheney> 2013-09-02 01:28:33 INFO juju supercommand.go:284 command finished
[01:29] <davecheney> you'l live :)
[01:29] <hazmat> davecheney, i'm using us-west-2 incidentally
[01:29] <hazmat> us-west-1 has higher pricing
[01:29]  * davecheney tried us-west-2
[01:30] <hazmat> davecheney,  http://pastebin.ubuntu.com/6053452/
[01:30] <hazmat> 36s compared to 17s
[01:30] <davecheney> hazmat: it's slow in us-west-2 'cos there are no tools
[01:30] <hazmat> davecheney, there's tools in us-west-1?
[01:31] <hazmat> i thought only in us-east
[01:31] <davecheney> i have no idea why
[01:31] <davecheney> tools are no region specific in ec2
[01:31] <davecheney> the automatic fallback to sync-tool is very confusing if you don't pass -v
[01:31] <davecheney> hazmat: http://paste.ubuntu.com/6053456/ us-west-1
[01:32] <davecheney> us-west-2 is taking much longer
[01:32] <davecheney> i can only assuming it's doing sync tools
[01:32] <hazmat> generally with fios/fiber to the home, i have pretty good bandwidth & latency.. in terms of ruling out client connectivity.
[01:33] <hazmat> davecheney, there's some sleep and retry logic in the ec2/s3 code for eventual consistency as well
[01:33] <davecheney> hazmat: if I can bootstrap in 25 seconds from australia
[01:34] <davecheney> isn't not a latency problem :)
[01:34] <hazmat> wow
[01:34] <hazmat> 2m9 vs 25s
[01:34] <davecheney> it's sync tools
[01:35] <davecheney> hazmat: still going ...
[01:35] <davecheney> us-west-2
[01:35] <hazmat> davecheney, plus it looks up tools multiple times..
[01:35] <hazmat> in bootstrap
[01:35] <hazmat> one to find/upload them, one to launch an instance
[01:36] <hazmat> which gets duplicated by the provisioning worker for every launch
[01:40] <davecheney> hazmat: http://paste.ubuntu.com/6053480/
[01:40] <davecheney> ends with a Fffffuuuuu
[01:40] <hazmat> 2m4s
[01:40] <davecheney> 'cos of sync tools
[01:40] <davecheney> workaround: don't use us-east-2
[01:41] <davecheney> west-2
[01:41] <hazmat> that's interesting i don't see the tool sync
[01:41] <davecheney> gotta use -v
[01:41] <davecheney> always -v
[01:41] <davecheney> use -v for everything
[01:41] <davecheney> got a question
[01:41] <davecheney> -v
[01:41] <davecheney> need answers
[01:41] <davecheney> -v
[01:41] <hazmat> i've been using --debug
[01:41] <hazmat> which seems like it should imply -v
[01:41] <davecheney> sure
[01:41] <davecheney> i use-v
[01:41] <davecheney> did i mention i use -v
[01:41] <davecheney> -v is great
[01:42] <davecheney> http://paste.ubuntu.com/6053487/
[01:42] <davecheney> wut
[01:42] <davecheney> it either is, or is not bootstrapped
[01:42] <hazmat> davecheney, i know that bug
[01:43] <hazmat> davecheney, its when you have a bucket but no environment, ie. shutdown from the console
[01:43] <hazmat> davecheney, the only resolution was to destroy the environment again
[01:43] <davecheney> whoo
[01:44] <hazmat> or manually empty the bucket..
[01:44] <davecheney> hazmat: http://paste.ubuntu.com/6053492/
[01:44] <davecheney> 25seconds
[01:46] <hazmat> davecheney, for comparison http://paste.ubuntu.com/6053494/
[01:46] <wallyworld> axw: i looked at the simplestreams branch - i marked it as lgtm so long as a few issues are fixed. let me know if you have any questions. as soon as it lands, i need to munge simplestreams format a bit
[01:46] <axw> wallyworld: okey dokey, thanks
[01:47] <davecheney> 2013-09-01 14:47:35 INFO juju.environs.tools tools.go:93 picked newest version: 1.13.2
[01:47] <davecheney> 2013-09-01 14:48:04 DEBUG juju.provider.ec2 storage.go:52 Creating bucket
[01:47] <davecheney> what the heck is it doing for 30 seconds there
[01:48] <davecheney> 2013-09-01 14:48:35 DEBUG juju.provider.ec2 ec2.go:394 ec2 user data; 12541 bytes
[01:48] <davecheney> 2013-09-01 14:48:56 DEBUG juju.provider.ec2 ec2.go:397 ec2 groups setup
[01:48] <davecheney> hazmat, whatever ec2 enpoint you are talking to
[01:48] <davecheney> it's screwed
[01:48] <hazmat> davecheney, that's us-east
[01:48] <hazmat> davecheney, its the same time for us-west
[01:48] <davecheney> sure, but bgp says we don't see the same thing
[01:49] <hazmat> yeah
[01:49] <axw> wallyworld: where did you try adding --noprofile/--norc?
[01:49] <wallyworld> axw: in the call which invoked bash
[01:49] <wallyworld> md := exec.Command("ssh", sshHost, "bash")
[01:50] <wallyworld> but i may have not done it right, i was in a hurry
[01:50] <axw> ok, that wouldn't work - bash doesn't actually get executed there
[01:50] <davecheney> axw, maybe need -t
[01:51] <axw> davecheney: ?
[01:51] <axw> ssh -t?
[01:51] <davecheney> otherwise bash won't have a pty
[01:52] <axw> davecheney: yeah.. don't need it here. not actually running a real ssh in the tests
[01:52] <davecheney> kk
[01:52]  * davecheney stops 'helping'
[01:52] <axw> ;)
[02:00] <axw> wallyworld: I'm not sure how to reproduce the problem. Can you please try "var sshscript = `#!/bin/bash --noprofile" in detection_test.go, when you have a minute
[02:00] <wallyworld> axw: sure, i'll just park some stuff and try it
[02:03] <wallyworld> axw: no good :-(. you could maybe reproduce it by having a ~/.shinit with a non zero exit code?
[02:03] <axw> wallyworld: tried that..
[02:03] <axw> hrm
[02:03] <wallyworld> hmmm. was you .shinit run?
[02:04] <axw> probably not :)
[02:04] <axw> it is if I run "sh"
[02:04] <wallyworld> so i'm confused
[02:04] <axw> I guess your bash profile is running something through sh?
[02:04] <wallyworld> ah, i think i might invoke it
[02:04] <wallyworld> elsewhere
[02:05] <axw> I'm sure we have other tests which do this though
[02:05] <axw> so I don't know why this one in particular would break
[02:05] <wallyworld> i have it in my .bashrc
[02:05] <wallyworld> BASH_ENV=$HOME/.shinit
[02:06] <wallyworld> but .bashrc should not be run, right?
[02:06] <thumper> wallyworld: what are you doing that is so special?
[02:06] <wallyworld> thumper: the line that fails is a mkdir -p foobar
[02:06] <thumper> axw: I suggest we just blame wallyworld and make him fix it
[02:06] <axw> hehe
[02:07] <thumper> wallyworld: what is in your .shinit?
[02:07] <wallyworld> except we shouldn't be running profile scripts when doing the ssh :-)
[02:07] <axw> wallyworld: so you could change --noprofile to --norc, but it's still a bit weird
[02:07]  * thumper reads that quickly as "shit init"
[02:07]  * axw snorts
[02:07] <axw> I did the same :)
[02:07] <thumper> heh
[02:08] <wallyworld> thumper: i have a bunch of exports, and a line to make a tmp dir cause i have /tmp mapped to ram. the line which errors in the tests is mkdir -p /var/tmp/mailman/logs
[02:08] <wallyworld> the test error is
[02:08] <thumper> wallyworld: why does it fail?
[02:08] <wallyworld> ...     "error detecting hardware characteristics: exit status 126 (/home/ian/.shinit: line 49: /bin/mkdir: Argument list too long\n" +
[02:09] <wallyworld> ...     "/tmp/gocheck-8674665223082153551/3/ssh: line 14: /tmp/gocheck-8674665223082153551/3/ssh: Argument list too long\n" +
[02:09] <wallyworld> ...     "/tmp/gocheck-8674665223082153551/3/ssh: line 14: /tmp/gocheck-8674665223082153551/3/ssh: Success)"
[02:09] <thumper> wallyworld: why have it in .shinit instead of .bashrc?
[02:09] <wallyworld> thumper: i call .shinit from my bashrc
[02:09] <thumper> why?
[02:09] <wallyworld> not sure now. there was a reason at some point
[02:09] <thumper> if you renamed it to something else, what fails?
[02:10] <wallyworld> if i rename it, the tests pass
[02:10] <wallyworld> but then it is not run
[02:10] <thumper> \o/
[02:10] <wallyworld> well, there is still the roblem that my .bashrc is being run
[02:10] <wallyworld> in order to call .shinit
[02:11] <wallyworld> and we shouldn't be doing that
[02:11] <thumper> well, no
[02:11] <thumper> /bin/sh loads .shinit
[02:11] <axw> wallyworld: can you try replacing --noprofile with --norc?
[02:11] <wallyworld> sure
[02:12] <wallyworld> damn. no good
[02:13] <axw> wtf
[02:13] <wallyworld> yeah, makes no sense to me
[02:15] <wallyworld> i'll just rename the shinit
[02:39] <axw> wallyworld: re "Please make this a big number so that we can ensure the fix actually works"
[02:39] <axw> that test is not testing the fix at all
[02:40] <axw> it's testing that standard JSON unmarshalling behaviour takes palce
[02:40] <axw> place*
[02:40] <wallyworld> ah, ok. i thought that the new unmarshall/marshall stuff was being invoked all the time
[02:40] <axw> if you unmarshal a number into an interface{}, you get a float64
[02:40] <axw> no, only if you go through ParseCloudMetadata
[02:40] <axw> because only then do you have a template value
[02:40] <wallyworld> ok, no problem. thanks for clarifying
[02:41] <axw> nps, I'll add a comment in the review too in case anyone else cares
[02:41] <wallyworld> did i make sense when i said i just wanted the marshall/unmarshall code moved out?
[02:41] <axw> yes
[02:41] <axw> I've kept "itemCollection" (the clone of ItemCollection) and the ItemCollection methods in json.go
[02:41] <axw> everything else has gone back
[02:41] <axw> is that right?
[02:42] <axw> ItemCollection methods = UnmarshalJSON & construct
[02:42] <wallyworld> yeah, i think that's good. i wanted the business logic / data model as it was, and the on the wire stuff separate to it's easier to grok etc
[02:42] <axw> cool
[02:42] <wallyworld> cause the user reading the simplestreams logic doesn't care about the json crap
[02:43] <thumper> dog walk time
[02:43] <wallyworld> and visa versa
[02:43] <wallyworld> ha, that last comment could also apply to thumper
[02:43] <wallyworld> even though it wasn't meant to
[02:48] <axw> davecheney: the azure bugs can be fixed pretty quickly it seems
[02:48] <axw> davecheney: any chance of slipping anything else in?
[02:49] <axw> wallyworld: have you seen this? https://bugs.launchpad.net/juju-core/+bug/1219123
[02:49] <davecheney> axw: too late
[02:49] <davecheney> release it tagged
[02:49] <davecheney> we can always back port
[02:49] <axw> okey dokey
[02:50] <wallyworld> axw: no, haven't seen that before
[03:28] <thumper> arse biscuits
[03:28] <thumper> some of our code is truly horrible
[03:28]  * thumper thinks
[03:45]  * thumper decides not to fix everything at once
[04:03] <wallyworld> axw: are you landing your simplestreams branch now?
[04:04] <axw> wallyworld: yes. do you want to make another pass, or shall I go ahead?
[04:04] <wallyworld> axw: nah, Just Do It. we can iterate as needed
[04:04] <axw> cool
[04:04] <wallyworld> i need to merge it into my work after it lands, and then change stuff to do with the data format
[04:05] <axw> okey dokey. let me know if there's something you'd like me to do
[04:06] <axw> also, sorry it took so long
[04:07] <wallyworld> no problem, it didn;t take long, it was fairly involved
[04:18] <axw> wallyworld: just merging with trunk, I'll let you know when the bot's done
[04:18] <wallyworld> yay, thanks
[04:24] <axw> or not, one of the tests is playing up
[04:41]  * thumper wonders how to withdraw a rietveld review
[05:01] <wallyworld> axw: i have school pickup, i check when i get back to see how the merge is going
[05:01] <axw> wallyworld: ok, later. fixing tests atm
[05:11]  * thumper uses some mocks for agent.Config
[05:11] <thumper> it feels GOOD
[05:14] <thumper> hmm...
[05:14] <thumper> WTF went wrong there...
[05:15] <thumper> copy and paste went wrong there
[06:02] <jam> axw: I bring up the SHA256 thing because it failed in the bot
[06:03] <axw> jam: ah right. yeah there was a bug in my test code, I was accidentally writing dynamic content to the fake tools files
[06:03]  * thumper is almost done
[06:03] <axw> must've been lucky with the gocheck temporary dir being the same on my machine
[06:06] <thumper> argh!!!
[06:06]  * thumper takes a deep breath
[06:06] <jam> thumper is never almost done
[06:06] <jam> :)
[06:06] <thumper> :P
[06:06] <jam> well, never *actually* done
[06:07]  * thumper leaves it for now
[06:10] <axw> jam: expect MS to call you if you've signed up for Azure
[06:10] <axw> they woke me up the other day..
[06:11] <jam> axw: yeah.
[06:12] <jam> axw: so when I "LGTM" with some comments, if you address and agree with the comments, you can feel free to just land it
[06:13] <axw> jam: ok, will do
[06:13] <axw> I'm just updating the default-precise comment now
[06:13] <axw> and testing
[06:34] <davecheney> 1.13.3 is released
[06:34] <davecheney> the lp builders are lagged
[06:34] <davecheney> i'll uploda the tarball and publish the release notes once the tools are uploaded
[06:34] <jam> thanks davecheney
[06:36] <davecheney> will look at the 1.14 branch next
[06:36] <davecheney> /s/branch/series
[06:41] <davecheney> i release 1.13.3 so y'all would stop putting bugs back in there :)
[06:49] <davecheney> https://launchpad.net/juju-core/+milestone/1.14.0
[07:08] <wallyworld> axw: just saw your test error - that's intermittent, i raised a bug 1219602
[07:08] <wallyworld> i resubmitted and it worked
[07:08] <axw> wallyworld: thanks, I was about to look into it...
[07:08] <axw> cool
[07:08] <wallyworld> np, that's why i pinged you to save you the trouble :-)
[07:09] <axw> wallyworld: it says "needs review" still?
[07:09] <wallyworld> axw: if a test run failes, the bot puts it back to needs review
[07:10] <wallyworld> you need to flip it to approved again
 i resubmitted and it worked  <- what worked?
[07:10] <wallyworld> axw: the landing bot ran the tests successfully and merged the branch
[07:11] <wallyworld> when i say resubmitted, i mean i marked the mp as approved
[07:11] <axw> oh ok
[07:11] <axw> yep..
[07:11] <wallyworld> and so the bot noticed and re did its thing
[07:12] <axw> I'm confused because it's not saying merged, but it doesn't matter. I'll do it again
[07:16] <wallyworld> axw: it's not saying merged because the merge did not happen because the tests failed
[07:16] <wallyworld> so the bot emailed the test failures and flipped the status back to needs approved
[07:16] <axw> wallyworld: yeah I get that, but I thought you said it passed
[07:17] <axw> sorry, I'm being a bit thick
[07:17] <wallyworld> it passed for *me* for my branch when i tried a second time
[07:17] <axw> ahh right, on a different MP
[07:17] <wallyworld> yeah, sorry
[07:17] <dimitern> morning!
[07:17] <axw> morning dimitern
[07:17]  * wallyworld goes to soccer
[07:21] <axw> wallyworld: it has finally merged
[07:21] <axw> enjoy soccer
[08:03] <jamespage> davecheney, I'm assuming that my next upload to saucy should be 1.14.0 right?
[08:03] <jamespage> and thats really just 'stable release of 1.13.x'?
[08:03] <jamespage> (need to phrase my changelog message right as I don't think its a huge jump from 1.13.2)
[08:36] <jam> jamespage: that sounds right to me
[08:36]  * jam heads out to run a couple of errands.
[08:41] <davecheney> jamespage: correct
[08:41] <davecheney> will be ready by weeks end if not sooner
[08:41] <davecheney> i wouldn't worry about 1.13.3
[09:14] <mgz> so, it's a no US day today
[09:20] <thumper> jam: hey, seen mramm?
[09:24] <mgz> thumper: I assume he's out as it's a US holiday today
[09:25] <thumper> mgz: he's in the UK :)
[09:26] <mgz> oh, then I guess not :)
[10:02] <jam> mgz:  /wave
[10:03] <jam> I haven't seen mramm all day anyway
[10:05] <mgz> hey jam
[10:17] <dimitern> https://codereview.appspot.com/13272045 - mgz, jam, please take a look (uniter api's remaining unit ops)
[10:24] <dimitern> fwereade: ^^?
[10:25] <fwereade> dimitern, sure
[10:26] <dimitern> fwereade: ty
[10:27] <mgz> dimitern: sure
[10:31] <jam> mramm: hey, good to see you around
[10:32] <mramm> jam: in the london office for the gui sprint
[10:33] <dimitern> mramm: hey, so we can book now for the sf sprint?
[10:34] <mramm> dimitern: yep
[10:34] <dimitern> mramm: cool!
[10:34] <dimitern> mramm: arriving 21, leaving 25 oct, right?
[10:34] <dimitern> mramm: or thereabouts
[10:42] <jam> dimitern: I think you need the final signoff from mramm before you can actually get the agency to book the travel
[10:42] <jam> but you could probably start the conversation.
[10:43] <dimitern> jam: well, following the steps in the mail, I'm filling in the form first, then will contact bts travel
[10:44] <jam> dimitern: right, so after filling in the form mramm gives a final signoff on it, and you get a confirmation ID that you need to share with BTS before they'll book anything
[10:44] <jam> I think you actually share the whole email with them.
[10:44] <dimitern> jam: ok
[10:45] <mgz> will miss the standup, will catch up when I'm back shortly after
[10:49] <fwereade> dimitern, couple of questions, not *quite* an LGTM, the Destroy test is the only one that gave me serious pause
[10:50] <dimitern> fwereade: ok
[10:52] <dimitern> fwereade: well, the uniter does call unit.Destroy
[10:52] <fwereade> dimitern, but not on itself
[10:52] <dimitern> fwereade: filter.go:453, uniter.go:498
[10:53] <fwereade> dimitern, bah, filter, I stand corrected
[10:53] <dimitern> fwereade: :) so it's ok then?
[10:55] <fwereade> dimitern, yeah, I think so
[10:55] <fwereade> dimitern, it might be neater to implement the test for a unit destroying its own subordinate, though, because that's the one that's least sensitive to future change
[10:55] <fwereade> dimitern, and you've already written that support code, so it should be easy ;p
[10:56] <dimitern> fwereade: ok, will do
[10:56] <fwereade> dimitern, thanks
[11:07] <dimitern> fwereade: hmm
[11:08] <fwereade> dimitern, eh, problems?
[11:08] <dimitern> fwereade: I'm not sure it's possible to do an api call for a subordinate if you've logged in as the principal
[11:09] <fwereade> dimitern, doesn't the principal destroy its own subordinates? maybe I misremembered
[11:09] <dimitern> fwereade: i mean, it'll return ErrPerm because the auth'ed entity tag won't match
[11:09] <fwereade> dimitern, modes.go:298
[11:09] <dimitern> fwereade: so the when logged in as a principal, you should be able to call Destroy() (and only that method?) on its subordinates as well
[11:10] <fwereade> dimitern, that's the only one I can think of offhand
[11:10] <dimitern> fwereade: ok, that'll require a few changes at server-side
[11:10] <fwereade> dimitern, hopefully minor?
[11:10] <dimitern> fwereade: they should be, yeah
[11:11] <fwereade> dimitern, cool, thanks
[11:11] <fwereade> dimitern, if it needs to be a separate CL so be it
[11:12] <dimitern> fwereade: yeah it seems more like that
[11:12] <dimitern> fwereade: more changes are needed actually - I need to be able to fetch a subordinate from a logged in principal
[11:13] <dimitern> fwereade: so what do you say to leaving it as is, adding a TODO to fix it and doing the fix in a follow-up?
[11:15] <fwereade> dimitern, LGTMed
[11:15] <dimitern> cheers
[11:15] <fwereade> dimitern, well, you don't need to get the subordinate for that piece of code
[11:15] <fwereade> dimitern, that's just a Destroy loop over SubordinateNames
[11:16] <dimitern> fwereade: not really
[11:16] <fwereade> dimitern, hell, the first 10 lines of that mode should really just be a "destroy all subordinates plskthx" api call
[11:17] <dimitern> fwereade: SubordinateNames returns names, not tags, and I need a uniter.Unit proxy object to call the server-side
[11:17] <dimitern> fwereade: so I have to construct it in place, it'll be a bit ugly
[11:17] <fwereade> dimitern, all the more reason to replace it all then -- but that's not the approach we agreed, I know
[11:18] <fwereade> dimitern, that said
[11:18] <fwereade> dimitern, why would we use names over the API? *shouldn't* they be subordinate tags? ;p
[11:19] <dimitern> fwereade: we return names, but take tags as args
[11:19] <fwereade> dimitern, that's incoherent
[11:20] <fwereade> dimitern, how widespread is it?
[11:20] <dimitern> fwereade: in most cases we use only tags, except for a few cases like SubordinateNames and the strings watchers
[11:20] <dimitern> fwereade: not much, but I have to check
[11:22] <fwereade> dimitern, so long as there's general agreement that the appropriate language is tags, not names, I'm reasonably happy
[11:22] <fwereade> dimitern, bugger, we have deployed lifecycle watchers that use names, haven't we?
[11:24] <dimitern> fwereade: so these return or use names: GetPrincipal, SubordinateNames,Relation (inside the RelationResult struct there's a ServiceName field), ReadRemoteSettings (only in the error message "cannot read...")
[11:25] <dimitern> fwereade: lifecycle watchers are notifywatchers I think
[11:26] <dimitern> fwereade: but the deployer uses a stringswatcher that returns names
[11:26] <fwereade> dimitern, ideally I think all those would be fixed before we deployed something that expected names
[11:26] <fwereade> dimitern, but the StringsWatcher thing has rather screwed us
[11:28] <dimitern> fwereade: yep, so I looked
[11:29] <dimitern> fwereade: stringswatchers, error messages, a few params struct fields, and these 2 methods of UniterAPI use names
[11:31] <dimitern> fwereade: standup
[11:33] <jam> TheMue: standup? https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471
[12:54] <dimitern> wow, so with some of the cli now using the api, cmd/juju tests running time increased like 5 fold
[13:05]  * dimitern lunch
[13:32] <dimitern> fwereade: hey
[13:32] <fwereade> dimitern, heyhey
[13:33] <dimitern> fwereade: the way uniter api works now, it calls Life when you call uniter.Unit(tag)
[13:33] <dimitern> fwereade: and that's the only way to get a unit proxy object
[13:33] <dimitern> fwereade: does Life has to work for subordinates as well? because that opens a different can of worms
[13:33] <fwereade> dimitern, I don't think so
[13:34] <fwereade> dimitern, I suspect a simple DestroyAllSubordinates will be the easiest way
[13:34] <dimitern> fwereade: so the client-side api has to distinguish between a principal and a subordinate
[13:34] <dimitern> fwereade: ah, so make a new method on unit - DestroyAllSubordinates then?
[13:34] <dimitern> fwereade: and the matching call at server-side
[13:34] <fwereade> dimitern, I think so
[13:35] <dimitern> fwereade: this will require some changes in the uniter as well
[13:36] <fwereade> dimitern, agreed
[13:37] <dimitern> fwereade: ok, will add a TODO for that as well
[13:38] <fwereade> dimitern, we're writing code either way
[13:39] <fwereade> dimitern, use your judgment
[13:39] <fwereade> dimitern, if it's cleaner to preserve the structure then that's ok too
[13:39] <dimitern> fwereade: it's not cleaner at all - it involves chaning LifeGetter to accomodate that special case
[13:40] <dimitern> fwereade: I prefer not to do it unless we need to
[13:40] <fwereade> dimitern, huh? surely not
[13:40] <fwereade> dimitern, auth is specified outside LifeGetter
[13:40] <fwereade> dimitern, it's the same getauth as deployer, surely?
[13:41] <fwereade> dimitern, ah not quite
[13:41] <fwereade> dimitern, but still
[13:41] <dimitern> fwereade: well, the auth func will get a lot more complicated, but yes LifeGetter might not need to change
[13:53] <dimitern> fwereade: well, the auth func will get a lot more complicated, but yes LifeGetter might not need to change<
[13:53] <dimitern> fwereade: oops, sorry
[13:54] <dimitern> fwereade: too many windows :)
[14:13] <dimitern> fwereade: there it is https://codereview.appspot.com/13426045
[14:35] <dimitern> fwereade: ping
[14:35] <fwereade> dimitern, hey, sorry, I'm looking
[14:36] <dimitern> fwereade: cheers
[14:49] <fwereade> dimitern, LGTM
[14:49] <fwereade> dimitern, sorry delay
[14:49] <fwereade> dimitern, although actually...
[14:49] <dimitern> fwereade: thanks!
[14:49] <fwereade> dimitern, how about putting that comment in uniter?
[14:50] <fwereade> dimitern, that's where we'll need to know it, not the other places, really
[14:50] <dimitern> fwereade: ah, good idea!
[14:59] <dimitern> fwereade: another, quite trivial https://codereview.appspot.com/13348050
[15:10] <fwereade> dimitern, a thought
[15:10] <fwereade> dimitern, if we have DestroyAllSubordinates, the only use of Subordinates would be better expressed plain old HasSubordinates
[15:11] <dimitern> fwereade: have to check
[15:11] <dimitern> fwereade: yeah, that seems sane
[15:12] <dimitern> fwereade: there are only 2 cases where it's used, and the the second one is just like HasSubordinates
[15:17] <dimitern> fwereade: so you're saying rename Subordinates to HasSubordinates, returning just a bool
[15:24] <dimitern> fwereade: the penultimate for today, promise :) https://codereview.appspot.com/13383046
[15:24] <dimitern> fwereade: the last will be a trivial rename s.unit -> s.stateUnit and unit -> apiUnit in client-side tests
[15:25] <fwereade> dimitern, <3
[15:28] <fwereade> dimitern, reviewed
[15:28] <dimitern> fwereade: tyvm
[15:40] <dimitern> fwereade: updated https://codereview.appspot.com/13348050
[15:43] <fwereade> dimitern, LGTM, couple of things to check
[15:47] <dimitern> fwereade: cheers
[15:53] <dimitern> fwereade: updated https://codereview.appspot.com/13383046/
[16:03] <hazmat> anyone tried local provider lately? i keep running into bug 1219887
[16:03] <_mup_> Bug #1219887: local provider needs to wait for upstart to load service file <juju-core:New> <https://launchpad.net/bugs/1219887>
[16:12] <rick_h> hazmat: used it on friday, what version? I was on the stable ppa I think
[16:22] <hazmat> rick_h, trunk of go and juju
[16:45] <dimitern> fwereade: last one - https://codereview.appspot.com/13472043
[16:46]  * dimitern bbiab
[17:15] <dimitern> fwereade: ping
[17:24] <dimitern> TheMue, mgz: still aroung?
[17:24] <dimitern> around
[17:26] <TheMue> dimitern: will take a look after dinner
[17:29] <dimitern> TheMue: cheers; it's a trivial renaming
[18:09] <TheMue> dimitern: you've got a LGTM
[18:16] <dimitern> TheMue: thanks!
[21:46] <thumper> WTF?
[21:46] <thumper> my review seemed to pick up all sorts of weird changes
[21:47]  * thumper grunts
[21:47] <thumper> because lbox uses the launchpad copy of the branch, not the local one
[22:04] <davecheney> mramm ping
[22:06] <davecheney> mramm ping
[22:06] <mramm> davecheney: pong
[22:09] <davecheney> goodbye sweet prince
[22:10] <davecheney> that's what you get for using a mac
[22:10]  * davecheney waves
[23:51] <thumper> gym time \o/