[00:08] <menn0> wallyworld, thumper: sorted out the test failure. it was due to a change in how mgo does retries. I copied the change from master and it now passes. I've tried running big chunks of our state tests and all is looking good. will propose shortly.
[00:08] <wallyworld> menn0: that's awesome, ty
[00:09] <perrito666> restore from ./juju-backup-20140728-1542.tgz completed <-- with failures but :D
[00:18] <thumper> wallyworld: https://github.com/juju/juju/pull/434 for backported mongo change
[00:19] <wallyworld> \o/ looking
[00:23] <menn0> thumper, wallyworld: this one needs a look before I can merge the big juju 1.20 change: https://github.com/juju/charm/pull/30
[00:23] <wallyworld> sure
[00:23] <wallyworld> menn0: tests pass?
[00:23] <menn0> thumper, wallyworld, sinzui: also, the bot doesn't seem to be noticing this: https://github.com/juju/juju/pull/433
[00:23] <menn0> what am I doing wrong?
[00:23] <menn0> wallyworld: yep, tests pass
[00:24] <thumper> menn0: did you still say merge?
[00:24] <sinzui> menn0, __fixes-1318366__
[00:24] <wallyworld> menn0: awesome, juju/charm change merged
[00:24] <menn0> thumper: no. so you need both.
[00:24] <thumper> menn0: AFAIK
[00:24] <menn0> in the same comment or it doesn't matteR?
[00:25] <wallyworld> thumper: your pr says it has conflicts
[00:25] <davecheney> menn0: use figlet(1)
[00:25] <sinzui> menn0, oh, but that isn't a merge command $$merge$$ to request merge testing.  __fixes-1318366__ is needed to convince CI to test it for the merge bot
[00:25] <thumper> wallyworld: really?
[00:25] <thumper> wtf?
[00:25] <thumper> sinzui: I thought you said 1.20 landings were ungated?
[00:25] <menn0> thumper: this is for master
[00:26] <sinzui> menn0, damn, I think github is swallowing __
[00:26] <thumper> menn0: mine isn
[00:26] <thumper> isnt'
[00:26] <sinzui> thumper, they are ungated, or were when I last looked
[00:26] <thumper> sinzui: https://github.com/juju/juju/pull/434#issuecomment-50698948
[00:27] <sinzui> ah, 1350493 is a regressions
[00:27] <menn0> looks like bug 1318366 isn't on the list of allowed fixes for master: "Does not match ['fixes-1350493', 'fixes-1347715', 'fixes-1342725']"
[00:27] <_mup_> Bug #1318366: jujud on state server panic misses transaction in queue <cloud-installer> <landscape> <orange-box> <panic> <performance> <sm15k> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1318366>
[00:27] <menn0> should I wait?
[00:27] <menn0> or __JFDI__
[00:27] <wallyworld> jfdi
[00:27] <sinzui> menn0, Yes please, your work predates the discovered of the regressions
[00:27] <menn0> sinzui: ok thanks
[00:27] <thumper> ah fark
[00:28] <sinzui> I will remove find something other than __ to avoid the markdown conflict
[00:32] <sinzui> CI will accept underscores and non- underscores for fixes-nnn to avoid the issue.
[00:32] <sinzui> I will remove the regression tag on 1.20 since there is no test showing the regression at this time
[00:33] <sinzui> I mean I removed "ci" from the bug 1350493 since ci didn't see the regressions
[00:33] <_mup_> Bug #1350493: 1.20.x local provider not running apt-get update <charms> <regression> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1350493>
[00:34]  * thumper rolls all the instructions into one
[00:35] <thumper> wallyworld: for some reason my 1.20 base branch didn't have upstream 1.20
[00:36] <thumper> merge accepted
[00:39] <menn0> thumper, wallyworld: here's the big 1.20 mgo change: https://github.com/juju/juju/pull/435
[00:39] <wallyworld> looking
[00:39] <thumper> menn0: oh, only 59 files?
[00:40] <menn0> thumper: yeah sorry. I tried to make it more but couldn't find anything else to search and replace.
[00:40] <thumper> heh
[00:40] <thumper> I say if all the tests pass, shipit
[00:42] <wallyworld> menn0: ty, +1
[00:43] <menn0> thumper: I haven't run all the tests but most of what's in the state and worker directories
[00:44] <menn0> merging now
[00:48] <davecheney> thumper: good news
[00:48] <davecheney> almost all the uses of authorizer.GetAuthEntity
[00:49] <davecheney> are in type switches
[00:49] <davecheney> so they are the same as a type switch on authorozer.GetAuthTag()
[00:50] <davecheney> thumper: and the ones that aren't when they get the entity, they just take it's tag anyway
[00:52] <davecheney> spot the bug
[00:52] <davecheney>                 loggedInUser := api.getLoggedInUserTag()
[00:52] <davecheney>                 if loggedInUser != argUser.Tag() {
[00:52] <davecheney>                         result.Results[i].Error = common.ServerError(fmt.Errorf("Can only change the password of the current user (%s)", loggedInUser.Id()))
[00:52] <davecheney>                         continue
[00:52] <davecheney>                 }
[00:52] <davecheney> ^ getLoggedInUser returns nil if the logged in user isn't a user
[00:52] <davecheney> say a machine or somethig
[00:52] <davecheney> so returning the error would panic the server
[00:53] <thumper> heh
[00:54] <davecheney> so i guess there isn't any coverage of this path ...
[00:55] <thumper> I guess not
[00:55] <davecheney> thumper: you're a winner
[01:10] <wallyworld> thumper: your change merged \0/, now just waiting for menn0 's
[01:10] <thumper> phew
[01:10] <wallyworld> hurry up bot
[01:18] <hazmat> is there any way to make the test runner print the name of test before it starts running it?
[01:18] <axw> only with -gocheck.vv I think
[01:18] <axw> which gives you all the logs too
[01:18] <hazmat> i'm using that, sadly that's not doing the trick working w/ mgo though
[01:19] <thumper> menn0: FWIW I got this failure on master: FAIL: upgrade_test.go:274: UpgradeSuite.TestLoginsDuringUpgrade
[01:19] <sinzui> A recent commit to master broke deploy in 4 clouds. Something about /var/lib/juju/db not existing
[01:19]  * sinzui gathers logs
[01:19] <hazmat> axw, maybe it is.. its just lost in the undifferentiated output
[01:20] <davecheney> thumper: https://github.com/juju/juju/pull/436
[01:20] <davecheney> ^ with fix and test
[01:20]  * thumper wonders if he broke trunk again
[01:22] <davecheney> thumper: can I land that fix ?
[01:23] <davecheney> menn0: you branch fialed to land
[01:23] <wallyworld> menn0: good news for you - gomaasapi needs updating too!
[01:23] <davecheney> yeah
[01:23] <thumper> davecheney: not yet I don't think
[01:23] <davecheney> just about to say that
[01:23] <davecheney> thumper: ok
[01:23] <davecheney> thumper: it wasn't really a question, more 'can I use the magic string to land it'
[01:23] <thumper> davecheney: I'd rather you didn't just now
[01:23] <davecheney> ok
[01:26] <waigani> thumper: https://github.com/juju/juju/pull/437
[01:34] <axw> wallyworld: https://github.com/juju/juju/pull/431
[01:34] <axw> fixes the manual provider regression
[01:34] <wallyworld> looking
[01:34] <axw> for real this time
[01:34] <axw> verified on the CI machine
[01:34] <sinzui> thumper, https://bugs.launchpad.net/juju-core/+bug/1350633
[01:34] <axw> wallyworld: also https://github.com/juju/juju/pull/430 unbreaks something I changed in the previous change
[01:48] <axw> wallyworld: thanks
[01:48] <wallyworld> np, thanks for fixing
[01:48] <axw> just thinking, maybe it'd be better to return an error if the output is something else
[01:49] <axw> i.e. not "no-agent-dir" or whatever
[01:49] <wallyworld> i wondered that
[01:49] <axw> then we'd see it in the output
[01:49] <wallyworld> yep
[01:49] <wallyworld> so long as it works in all circumstances
[01:50] <axw> it's only going to consider stdout still
[01:50] <axw> so it should be fine
[01:52] <thumper> sinzui: ok, on it
[01:54] <perrito666> axw: tx for the review on restore
[01:54] <axw> perrito666: nps
[01:54] <perrito666> I was really needing a second pair of eyes on that thing
[01:56] <thumper> sinzui: fuck fuck fuckity fuck, found it (I think)
[01:56] <thumper> yep
[01:56]  * thumper gets a patch ready
[01:56]  * thumper thinks of how to test it
[01:57]  * thumper wonders why the existing test didn't fail
[01:58] <menn0> davecheney, wallyworld: back from lunch. I'll deal with the failed merge after the team meeting.
[01:59] <wallyworld> np
[01:59] <menn0> thumper: do you have more detail on the UpgradeSuite.TestLoginsDuringUpgrade failure you saw?
[01:59] <thumper> menn0: only the scrollback
[01:59] <thumper> I'll look in a miute
[02:02] <sinzui> thumper, great the --debug I ran didn't give me any more information than the console output. I did find another test instance that has be deleting for more than a day in HP. good I get to write a support ticket
[02:02] <thumper> sinzui: I know what the problem is, just not sure why the tests didn't catch it
[02:17] <perrito666> natefinch: you are not around for the meeting right?
[02:27] <perrito666> davecheney: its odd, you are the one I hear the best next to jeese
[02:28] <perrito666> and I think we are as far apart (network wise) as topologically possible
[02:28] <davecheney> perrito666: hangouts appear to be point to point based, so some sound ok, others are complete disasters
[02:29] <perrito666> well, mystery :) Ill try to have more meetings with you :p I hear you better than almost everyone else
[02:29] <perrito666> ok ppl almost midnight here, see you all tomorrow, cheers
[02:30]  * perrito666 turns into a pumpkin
[02:32] <davecheney> perrito666: it's because I have a loud mouth
[02:33] <menn0> davecheney, wallyworld: I don't understand why this happened: https://github.com/juju/juju/pull/435#issuecomment-50702449
[02:33] <davecheney> menn0: toptip: don't trust godeps
[02:33] <davecheney> i think it's fucked
[02:33] <davecheney> it tells you it's updated to the correct rev
[02:33] <davecheney> but it lies
[02:33] <wallyworld> huh?
[02:33] <wallyworld> gomaas was never updated
[02:33] <menn0> hmm ok
[02:33] <wallyworld> was it?
[02:34] <wallyworld> gomaas also needs the import path changes
[02:34] <wallyworld> afaik, godeps works ok now that it has the -f option
[02:35] <davecheney> wallyworld: your experience differs from mine
[02:35] <wallyworld> :-
[02:35] <wallyworld> (
[02:35] <davecheney> i have found it to be unreliable since growing the ability to update if a rev is missing
[02:35] <wallyworld> ok, shame
[02:35] <wallyworld> i wish Go as a platform supported something better
[02:36] <wallyworld> not like this problem is new or anything
[02:36] <menn0> davecheney, wallyworld: well I look at my current gomaasapi copy and it indeed has references to labix.org/v2/mgo/
[02:36] <menn0> so I have no idea how builds and tests are working
[02:36] <davecheney> menn0: then the hash your using isn't the same one as dependencies.tsv
[02:37] <wallyworld> menn0: i think you still have labix source locally
[02:37] <wallyworld> but the bot doesn't
[02:37] <thumper> aarg!!!
[02:37] <thumper> found out why the tests passed
[02:37] <wallyworld> and......
[02:37] <davecheney> wallyworld: menn0 yeah, that could be it
[02:37] <wallyworld> drumroll
[02:37] <menn0> yep, that's exactly it
[02:37]  * davecheney holds breath
[02:38]  * menn0 deletes the old repo
[02:38]  * davecheney is breathless with ................ anticipation
[02:38]  * wallyworld taps fingers
[02:38]  * wallyworld holds breath
[02:38] <davecheney> OUT WITH IT MAN!
[02:39] <thumper> wallyworld: mocking
[02:39] <wallyworld> ah
[02:39] <wallyworld> ffs
[02:39] <wallyworld> \o/
[02:39] <thumper> s.PatchValue(mongo.AvailSpace, <-- said a constant
[02:39] <thumper> new function makes sure the directory exists
[02:39] <davecheney> wallyworld: let me tell you about apiserver/testing/fakeauthorizer some day
[02:40] <wallyworld> davecheney: noooooooo!
[02:40] <davecheney> wallyworld: thumper will tell you all about it when he tucks you in next week
[02:40] <wallyworld> ooooh
[02:40] <wallyworld> can't wait
[02:41]  * wallyworld likes thumper's good night kisses
[02:41] <axw> menn0: did you update the gomaasapi rev in dependencies.tsv in 1.20?
[02:41] <axw> I bumped it in master only
[02:42] <davecheney> axw: that'll be it
[02:44] <menn0> axw: yep I'm just pushing that now
[02:45] <thumper> wallyworld: https://github.com/juju/juju/pull/438
[02:45] <menn0> axw: it took me a while to figure out why everything worked on my machine without that change. turns out I still had the old labix mgo hanging around
[02:45] <wallyworld> looking
[02:46]  * thumper fixes 1.20
[02:46] <wallyworld> thumper: goes to show one has to be careful when writing mocks - just the correct bits need to be mocked out and nothing else
[02:47]  * thumper nods
[02:48] <thumper> damn git and it's auto commit shit
[02:48] <wallyworld> "damn git" without the qualifier is what you meant i think
[02:51] <thumper> wallyworld: and the backport https://github.com/juju/juju/pull/439
[02:52] <wallyworld> hmm, where has i seen that diff before?
[02:53] <thumper> sinzui: I do like the __JFDI__ flag, and the bold actually fits
[02:54]  * thumper has quick dogwalk before school ends
[03:09] <axw> review for https://github.com/juju/juju/pull/440 please? should fix the windows bootstrap regression
[03:09] <menn0> wallyworld: I can see that the test run for the 1.20 changes already has at least one failure
[03:10] <menn0> :(
[03:10] <menn0> looking in to it now
[03:10] <wallyworld> ok
[03:17] <axw> wallyworld: I don't follow your comment about precise
[03:17] <axw> I'm just using "trusty" because the series is used to infer the OS
[03:17] <axw> it could be precise, quantal, trusty, ...
[03:18] <wallyworld> axw: i thought that people running precise would get confused if they saw a /var/lib/juju/data/trusty dir
[03:18] <wallyworld> "wtf, i'm on precise, why is juju saying trusty"
[03:18] <thumper> axw: is there no other reasonable series we can use at that callsite?
[03:18] <axw> it won't be in there
[03:18] <thumper> not one that is passed in?
[03:18] <axw> wallyworld: it'll just be /var/lib/juju
[03:19] <menn0> wallyworld, axw: does this ring any bells? http://paste.ubuntu.com/7910716/
[03:19] <wallyworld> axw: oh, ignore me
[03:19] <menn0> it's failing on 1.20 for me with the newer mgo
[03:19] <axw> thumper: I could just change it to "/var/lib/juju" and do away with the call altogether
[03:19] <wallyworld> axw: i misread it, sorry
[03:19] <menn0> in CI too
[03:19] <axw> menn0: looking
[03:19] <wallyworld> axw: that helper function is what i was referring to
[03:19] <wallyworld> doh
[03:19] <menn0> axw: the test itself is the same in master
[03:20] <axw> menn0: hmm no sorry
[03:20] <menn0> axw: thanks. I'll keep digging.
[03:21] <thumper> menn0: I think I have seen that intermittently once or twice
[03:21] <menn0> thumper: it could be that the timeout is a little tight
[03:22] <menn0> and perhaps the fix to this panic changes mgo's timing. the test is about watchers.
[03:23] <wallyworld> menn0: that error doesn't ring a bell. the only wather timing issues i know of are in state/watcher
[03:24] <wallyworld> axw: my vote is just to use /var/lib/juju with a TODO
[03:25] <axw> righto, will change
[03:25] <menn0> now I can't get that test to fail on my machine. I'm going to increase the timeout a bit.
[03:29] <wallyworld> menn0: don't you just love tests with timeouts? sigh
[03:30] <menn0> wallyworld: well the timeout is only in case the code under test doesn't work ... but unfortunately the code needs most of that timeout to do it's thing
[03:30] <wallyworld> menn0: "we" should be using channels and signals for tests that need coordination, not timeouts
[03:31] <wallyworld> but most of our tests are bad in that respect
[03:32] <thumper> hmm.... MachineSuite.TearDownTest... Panic: not authorized for query on presence.presence.beings (PC=0x414686)
[03:32] <menn0> wallyworld: it IS using channels. the timeout is used for the maximum time to wait for something to come back from the channel. the code is dependent on the watcher frequency which is why it has to wait.
[03:32] <menn0> so the test isn't THAT bad
[03:32] <wallyworld> menn0: ok, sorry :-) i spoke without looking at the code
[03:32] <menn0> it should probably patch the watcher frequency so it doesn't have to wait so long
[03:32]  * wallyworld is scared by bad tests
[03:32] <menn0> but I don't know if that would have other bad effects
[03:33] <thumper> also...  Panic: local error: bad record MAC (PC=0x414676)
[03:33] <wallyworld> menn0: there's a way to manually trigger the watcher
[03:33] <wallyworld> thumper: that's a mongo 2.4 bug
[03:33] <thumper> wallyworld: ok
[03:33] <wallyworld> hopefully fixed in 2.6
[03:33] <wallyworld> hence the drive to port juju to mongo 2.6
[03:34] <menn0> wallyworld: this test appears to be fairly high level so I don't know if that applies
[03:34] <menn0> I'm sure there's a way to make it faster
[03:34] <menn0> but I'm not going to try and solve that now
[03:34] <menn0> there's a TODO already
[03:34] <wallyworld> menn0: yep. for now i'd to the minimum
[03:35] <menn0> actually I think I see the problem
[03:35] <menn0> there could be a race
[03:35] <wallyworld> thumper:  that not authorised panic is a worry - it can happen with the new session copy stuff if there's a race
[03:35] <wallyworld> since a wrong session without credentials is used to connect
[03:35] <wallyworld> does it only happen every so often?
[03:35] <thumper> wallyworld: cmd/jujud tests
[03:36]  * thumper is running the tests again
[03:36] <wallyworld> from what i've seen, given al the improvements to tests over the past several weeks, the cmd/jujud tests are the main ones still failing
[03:42] <thumper> wallyworld: succeeded that time
[03:42] <wallyworld> ah, intermittent tests
[03:44] <marcoceppi> anyone know, in the actions spec
[03:44] <marcoceppi> is it action.yaml or actions.yaml?
[03:44] <wallyworld> yes
[03:44] <wallyworld> :-P
[03:44]  * marcoceppi waddles away
[03:44] <wallyworld> sorry :-)
[03:44] <wallyworld> i don't know which one
[03:44] <marcoceppi> haha, it's fine
[03:45] <marcoceppi> I'm trying to dig up the spec
[03:45] <wallyworld> marcoceppi: in the code, it seems to be actions.yaml
[03:45] <wallyworld> in juju-core code that is
[03:45] <marcoceppi> wallyworld: interesting that it's pluarl but metadata and config aren't
[03:45] <wallyworld> yeah
[03:46] <wallyworld> i have had no involvement so can't comment
[03:46]  * marcoceppi wonders if he should call it benchmark or benchmarks.yaml
[03:46] <wallyworld> marcoceppi: well, it is environments.yaml for example
[03:46] <marcoceppi> wallyworld: ah, true, good point
[03:46] <marcoceppi> I guess pluarl is depending on how well the word sounds :)
[03:47] <wallyworld> i'd go with plural
[03:47] <marcoceppi> I'll go with plural form
[03:47] <marcoceppi> yeah
[04:11] <axw> thumper: sorry, I thought you were working on the master branch - I shouldn't have changed the status of that bug :)
[04:24] <davecheney> uh,oh
[04:24] <davecheney> lucky(~/src/github.com/juju/juju) % git pull upstream master
[04:24] <davecheney> fatal: unable to access 'https://github.com/juju/juju.git/': Could not resolve host: github.com
[04:49] <menn0> wallyworld, sinzui: the mgo fixes for 1.20 are in! *\O/*
[04:50] <menn0> davecheney: I've had that a bit today as well (but my internet link has been a bit flaky too)
[04:50] <wallyworld> menn0: whoo hoo
[04:50] <wallyworld> ty
[04:51]  * menn0 updates the LP bug
[04:55] <davecheney> thumper, wallyworld I would like permission to land this, https://github.com/juju/juju/pull/442
[04:55] <davecheney> I'm tired to skipping over this test failure
[04:56] <wallyworld> davecheney: go for it
[04:57] <davecheney> wallyworld: thanks, i helps as I'm working in that area daily
[04:58] <wallyworld> no problem at all, nice change
[05:05] <davecheney> Oh, this change was actuall Go 1.4
[05:05] <davecheney> nm
[05:05] <davecheney> what is important is there are some improvements in the race detector coming soon to 1.4 dev
[05:05] <davecheney> and I want to be able to run juju under this improved race detector
[05:05] <davecheney> given the plethora of problems we have at ht emoment
[05:10] <menn0> ericsnow: ping?
[05:11]  * ericsnow hides
[05:11] <ericsnow> menn0: hi :)
[05:12] <menn0> ericsnow: do you want to do a quick hangout re the backup work? it might be more efficient.
[05:13] <ericsnow> menn0: sure, I really should have gone to bed hours ago, but at this point I'm not going to sweat it :)
[05:13] <menn0> ericsnow: I don't have much time before I need to go so I promise it'll be quick :)
[05:14] <menn0> ericsnow: https://plus.google.com/hangouts/_/gthfw6mxzrcsonn5bzqoqdb5iya?authuser=1&hl=en-GB
[05:14] <menn0> ericsnow: https://plus.google.com/hangouts/_/gthfw6mxzrcsonn5bzqoqdb5iya?authuser=1&hl=en-GB
[05:31] <davecheney> thumper, wallyworld large email about FakeAuthorizer sent to the list, enjoy!
[05:35] <davecheney> jcw4|away: this test has been broken for weeks
[05:35] <davecheney> http://paste.ubuntu.com/7911495/
[05:35] <davecheney> is it on your schedule to fix ?
[05:38] <davecheney> jcw4|away: the test failure stems from the caller expecting actions to be returned in a set order
[05:42] <ericsnow> *END* *OF* *DAY*
[06:18] <wallyworld> davecheney: jeez, it's not good when a mock breaks the contract implemented by the thing it is mocking
[06:19] <davecheney> wallyworld: indeed
[06:19] <davecheney> wallyworld: ideally, if I do this properly, we won't need a mock at all
[06:20] <wallyworld> \o/
[06:20] <davecheney> there will just be apiserver.TagAuthenticator
[06:32] <davecheney> wallyworld: https://github.com/juju/juju/pull/443
[06:32] <wallyworld> looking
[06:34] <davecheney> wallyworld: not ugrent
[06:34] <davecheney> urgent
[06:35] <wallyworld> davecheney: already +1 :-)
[06:35] <davecheney> this is part of unfucking FakeAuthoriser
[06:35] <davecheney> wallyworld: it'll wait til the trunk is unblocked
[06:35] <wallyworld> ok
[06:35] <davecheney> i'm doing a poor man's git pipeline
[06:35] <wallyworld> i miss lp for that
[06:57] <marcoceppi> Why can't I use juju run against a subordinate?
[07:07] <rogpeppe> is there an easy way to tell the current blocked status of commits to juju-core? i *think* that it's currently blocked by #1345638 (only) but it would be nice to have a definitive way to tell other than trying a $$merge$$
[07:07] <_mup_> Bug #1345638: ec2 changes? rising failure rate in ec2 health checks <ec2-provider> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1345638>
[07:07] <rogpeppe> marcoceppi: i don't see why you shouldn't be able to
[07:08] <rogpeppe> marcoceppi: what error do you see?
[07:08] <marcoceppi> rogpeppe: currently getting this
[07:08] <marcoceppi> juju run --unit subordinate/0 "cabs status"
[07:08] <marcoceppi> ERROR subodinate/0 is not a principal unit
[07:08] <marcoceppi> rogpeppe: should I file a bug?
[07:10] <rogpeppe> marcoceppi: yes - it does seem to be a deliberate decision, but i can't immediately think of a reason why you shouldn't be able to do it.
[07:10] <marcoceppi> rogpeppe: cool, this will really help unblock me with some stuff around benchmarking
[07:11] <rogpeppe> marcoceppi: note: i wasn't involved in doing juju-run at all - there may well be a good reason why it doesn't allow it
[07:11] <marcoceppi> rogpeppe: anyone you know off the top of your head i could ping for more clarification?
[07:12] <rogpeppe> marcoceppi: fwereade might know. or axw. otherwise i think thumper is the man.
[07:13] <axw> hmm, I don't know why
[07:13] <fwereade> marcoceppi, rogpeppe: can't think why offhand. are there maybe issues around ssh to subordinate units that juju run falls foul of?
[07:14] <rogpeppe> fwereade: i don't see why it should
[07:14] <marcoceppi> fwereade: I can juju ssh to subordinate/0 without issue
[07:14]  * marcoceppi is scouring the mailing list atm
[07:14] <fwereade> marcoceppi, it's evidently not that then :)
[07:15] <marcoceppi> I'll open a bug and see if thumper or axw chime in
[07:15] <rogpeppe> marcoceppi: how about proposing a trivial fix for the issue (just remove the unit.IsPrincipal check) and try to get a review off thumper?
[07:15] <rogpeppe> marcoceppi: or that
[07:16] <marcoceppi> rogpeppe: ah, was going to check next how hard it woudl be to patch
[07:16] <marcoceppi> if it's just a line or two I'll do that
[07:16] <rogpeppe> marcoceppi: it's just one if condition
[07:16] <marcoceppi> rogpeppe: cool, I'll go that route then
[07:16] <rogpeppe> marcoceppi: github.com/juju/juju/state/apiserver/client/run.go:68
[07:16] <marcoceppi> and duke it out in a pull request
[07:16] <marcoceppi> rogpeppe: ta!
[07:17] <fwereade> marcoceppi, yeah, should be a trivial fix -- IIRC AssignedMachineId does work for subordinates, so just drop the IsPrincipal() check and see what happens
[07:18] <fwereade> marcoceppi, get thumper's opinion on the PR, though, he might remember some important reason I've forgotten
[07:18]  * fwereade observes that rogpeppe said all that already
[07:18]  * fwereade slinks off
[07:18] <marcoceppi> fwereade: ack, I'll take a stab at it later tonight and just work around it for now. I'd want to compile/test as well to make sure it addresses my issue and actually works
[07:19] <rogpeppe> :-)
[07:19] <marcoceppi> thanks for the help fwereade and rogpeppe o/
[08:03] <axw> can someone review please: https://github.com/juju/juju/pull/445  <- fixes a critical bootstrap bug on master, 1.20 will come shortly
[08:04] <TheMue> axw: *click*
[08:07] <voidspace> axw: change looks fine to me (I'll let TheMue do formal review)
[08:08] <axw> thanks
[08:08] <voidspace> axw: the PR says ""With recent changes, we were leaving the installation of mongodb until too late"
[08:08] <voidspace> axw: *which* changes made this difference?
[08:09] <axw> voidspace: thumper fixed a bug where we were reinstalling/restarting the upstart service unnecessarily
[08:09] <axw> but left the installation bit where it was
[08:09] <TheMue> axw: +1
[08:09] <voidspace> ok, cool
[08:09] <axw> TheMue: thanks
[08:09] <voidspace> just wanted to understand the need
[08:10] <TheMue> axw: and btw thx for the initial comment describing WHY and not WHAT has changed.
[08:10] <TheMue> axw: just reviewd another PR this morning where the motivation for the change was missing
[08:11] <axw> no worries (though evidently could've been better). I like to know why things are done too ;)
[08:12] <TheMue> axw: yeah, helps when doing the review
[08:12]  * TheMue has to admit that he has to improve himself here
[08:13] <voidspace> heh, all round I think :-)
[08:16] <TheMue> btw, this morning I’ve seen a pattern to avoid a large number of arguments. here the args are in a struct and this is passed as variadic
[08:16] <TheMue> inside the function it is checked if 0 or 1 of these structs is passed
[08:16] <TheMue> and then the values are checked or a default is taken
[08:17] <TheMue> somehow this looks a bit strange
[08:17] <TheMue> what I like more is a pattern by Rob which can be found here http://commandcenter.blogspot.nl/2014/01/self-referential-functions-and-design.html
[08:18] <TheMue> it’s a bit more code, but when used it reads really good
[08:18] <TheMue> fwiw ;)
[08:19] <axw> that would be quite a lot of code, seems like it'd be overkill except in public APIs
[08:19] <axw> it is neat
[08:20] <axw> can't say I've seen any optional/variadic struct signatures - that sounds a bit unusual for the codebase
[08:20] <TheMue> axw: I found it in state, one already exists and one has copied this in the PR I’ve reviewd
[08:21] <TheMue> axw: one moment, will look for the file
[08:23] <TheMue> axw: oh, just have seen that it’s in a testing package, testing/factory/factory.go, line 88
[08:24] <TheMue> axw: so for testing code it may be ok
[08:25] <axw> I see
[08:26] <axw> I'd be tempted to make a second function, MakeUserDefaults
[08:26] <axw> which calls the other with default values
[08:30] <marcoceppi> Is there someone I need to ping or a review queue for pull requests agianst core?
[08:30] <TheMue> or you have to pass a struct but it can be empty (which leads to defaults)
[08:32] <TheMue> marcoceppi: the OCR (see https://docs.google.com/a/canonical.com/spreadsheets/d/1iQLLOWrjzxddm5VhYWYi0-2k3xI6wTMlpkvnVNJCYGY/edit#gid=0) can be pinged
[08:32] <TheMue> marcoceppi: or simply asking here
[08:49] <TheMue> marcoceppi: you talk about 447? change looks ok but I’m missing a change in the according unit tests
[09:00] <marcoceppi> TheMue: I don't think the unit tests ever covered this. When I ran the test post-change it still worked
[09:00]  * marcoceppi is really not that good at go
[09:02] <marcoceppi> TheMue: http://paste.ubuntu.com/7912806/
[09:03] <TheMue> marcoceppi: yeah, we have several uncovered aspects ;)
[09:03] <marcoceppi> since it's removing a restriction that was not already covered, how would you recommend I proceed?
[09:04] <TheMue> marcoceppi: so based on the existing test base and your live tests it’s OK. if there before would have been a test expecting an error this would fail now
[09:05] <marcoceppi> TheMue: right, I checked for that but then I read too much golang and got dizzy ;)
[09:06] <TheMue> marcoceppi: adding a test for a removed restriction, hmm, dunno how to do it. only by removing an existing test like described above. but so?
[09:06] <TheMue> marcoceppi: then I would say LGTM and it can be merged
[09:06] <TheMue> marcoceppi: but hey, dizzy by golang? no :D
[09:06] <marcoceppi> ideally I'd want to s.State.AddService('subordinate') but I have no idea how to distiguish a service as a subordiante
[09:07] <marcoceppi> then make sure that subordinate reports back it's units in run_test.go around line 77
[09:07] <marcoceppi> so regressions don't occur
[09:07]  * marcoceppi does some more digging
[09:12] <voidspace> axw: ping, you still around?
[09:12] <axw> voidspace: pong, I am
[09:13] <voidspace> axw: so I'm removing the code that opens the stateport to the outside world in the various providers
[09:13] <voidspace> axw: I've done ec2 and openstack
[09:13] <voidspace> axw: azure is slightly different
[09:13] <voidspace> axw: provider/azure/environ.go
[09:14] <voidspace> axw: it looks like I just delete the state-port endpoint, lines 794+
[09:14] <marcoceppi> yup, I'm over my head
[09:14] <voidspace> axw: does that sound right to you?
[09:14] <axw> voidspace: looking/refreshing memory
[09:14] <voidspace> sure :-)
[09:14] <marcoceppi> yup, I'm in over my head
[09:14] <axw> voidspace: while you're here, can you delete that TODO in getInitialEndpoints please
[09:14]  * TheMue laughs about http://geek-and-poke.com/geekandpoke/2014/7/31/hansel-and-geekel
[09:16] <axw> voidspace: yep, you can just remove the StatePort bits
[09:16] <voidspace> axw: okey-dokey, and thanks
[09:17] <axw> nps
[09:17] <axw> voidspace: ooh, hold on
[09:17] <axw> complicated
[09:18] <voidspace> axw: my only concern would be if it prevents us using the *local port* too
[09:18] <axw> if we just remove it, listPorts will start showing StatePort
[09:18] <voidspace> axw: as available?
[09:18] <axw> it won't
[09:19] <axw> voidspace: actually I don't think it matters. for some reason the code tries to mask the state port from the result of Ports
[09:19] <axw> but... a unit should not be opening that port
[09:19] <voidspace> axw: and why would it matter if a unit opens that port?
[09:19] <voidspace> axw: unless the unit is deployed to a state server I guess
[09:19] <axw> well, it'll be opening up mongo if the unit is running on a state server
[09:19] <voidspace> which we allow
[09:19] <voidspace> rught
[09:19] <axw> right
[09:19] <voidspace> *right
[09:20] <axw> I think we should handle that at a higher level though
[09:20] <voidspace> axw: right, it shouldn't be the job of every separate provider to prevent that
[09:22] <axw> voidspace: so I think the idea is that we don't want to report that we've internally opened a port, but I actually don't know what that affects
[09:22] <axw> if anything
[09:22] <voidspace> we don't want to report that we've opened it? But the change is that we *don't* open it. So if the desire is to not report it, then surely that won't change...
[09:22] <axw> upgrades
[09:23] <axw> an existing instance will have opened it
[09:23] <axw> if we then remove the port from the mask, it'll show up
[09:23] <voidspace> ah
[09:23] <voidspace> security by obscurity?
[09:23] <voidspace> in the hope that no-one will ever read the source code
[09:23] <voidspace> or the logs
[09:24] <axw> I don't know if that's the point - I hope not
[09:24] <voidspace> heh
[09:24] <voidspace> maybe just not to leak internal details to user facing information
[09:24] <voidspace> if they're asking which ports are open they *probably* want to know which ones *they* opened
[09:25] <voidspace> nonetheless, I have a test failure due to this
[09:25] <axw> voidspace: I'm just looking at the firewaller; looks like it's to stop the firewaller from closing ports it didn't tell the instance to open
[09:25] <voidspace> so l will go on lunch
[09:26] <axw> enjoy
[09:26] <voidspace> axw: ah, ok
[09:26] <voidspace> axw: what's the implication of that?
[09:26] <axw> voidspace: we need to preserve the mask
[09:26] <voidspace> axw: surely that's good - if we no longer mask the state port it *will now* be closed on upgrade
[09:26] <voidspace> which is what we want
[09:26] <axw> heh I guess so :)
[09:27] <axw> I'm sold
[09:27] <voidspace> it means we don't need an explicit upgrade step to close the port...
[09:27] <voidspace> :-D
[09:27]  * voidspace lurches to lunch
[09:33] <jam1> voidspace: better to lurch towards lunch, than to lurch during/after lunch, I guess
[09:33] <voidspace> heh
[09:33] <voidspace> I lurch a lot
[10:03] <mattyw> fwereade, ping?
[10:03] <wallyworld> mgz_: 1:1 time
[10:04] <mattyw> fwereade, If possible I'd like to schedule some time with you to talk to emerald squad about some stuff - I was going to shove something in the diary - wondered if you had a preference of timing?
[10:12] <perrito666> morning
[10:21] <TheMue> perrito666: morning
[10:25] <rogpeppe> fwereade: i'd appreciate your review of this since we discussed it recently, if you have a little time: https://github.com/juju/charm/pull/31
[10:33] <rogpeppe> other reviews also appreciated, please
[10:45] <voidspace> TheMue: jam1: coffee on the boil - be at standup in 3 minutes or so...
[10:45] <jam1> kk
[10:45] <TheMue> just fetched my headset
[10:49] <voidspace> in
[11:04] <TheMue> voidspace: afk for lunch, so we’ll talk later
[11:09] <voidspace> TheMue: sure, I have to finish this ticket first anyway
[11:57] <wallyworld> katco: mgz_: axw: still in other meeting, will ping soon for standup
[12:14] <perrito666> hey congrats and thanks to the people involved in the style and review guide, that helps a lot
[12:17] <jam1> cmars: thanks to your patch I did get the client side stuff landed today.
[12:17] <perrito666> jam1: hey, have a moment?
[12:17] <cmars> jam1, excellent
[12:17] <bac> hi mgz_, are you using jenkins-github-lander on your CI?
[12:17] <cmars> jam1, i'm updating my login API accordingly
[12:18] <jam1> what's up perrito666
[12:18] <rogpeppe> cmars: any chance you could take a look at https://github.com/juju/charm/pull/31 please, as it's changing some of your code, i believe? (i got agreement from fwereade that this was a reasonable way to move forward)
[12:18] <bac> sinzui: ^^
[12:19]  * cmars takes a look
[12:19] <perrito666> jam1: some time ago you asked me about a running aws instance and also to vlad, how do you see who does the instance belong? I see one running since the 24th and seems to be a leftover state server
[12:19] <perrito666> but I cannot determine who does it belong to
[12:19] <jam1> what region is it in ?
[12:20] <perrito666> us-east-1
[12:20]  * thumper pops on briefly
[12:20] <thumper> mattyw: I'm going to take the names branch for user tags, unless you want to move it forwards
[12:20] <thumper> mattyw: ok with that?
[12:20] <jam1> perrito666: the only one I see in us-east was started July 31, 2014
[12:21] <perrito666> jam1: ah, cool, it was destroyed yesterday then :) sorry I made a todo note to ask you when I noticed the instance yesterday
[12:21] <jam1> perrito666: generally I know because the juju environment name is part of the security group, and wallyworld is the only one that names it 'amazon'
[12:21] <perrito666> ehh lol
[12:21] <jam1> perrito666: and I ask that people name their environments with their name in them
[12:21] <jam1> like mine is "amz-jam"
[12:22] <perrito666> I thought the user was stored somewhere in the aws web
[12:22] <jam1> perrito666: I would have hoped IAM credentials could let you track that, but I haven't seen it anywhere
[12:22] <perrito666> jam1: I do too but amazon was a bit too generic
[12:22] <mattyw> thumper, I was just commenting on the pr actually
[12:22] <mattyw> thumper, I've got a 'problem' with it - if you want to carry it on I'm fine with that
[12:22] <thumper> did you comment your problem?
[12:23] <mattyw> thumper, I will have done in about 2 minutes
[12:23] <thumper> ok
[12:23] <jam1> perrito666: we might also be able to grab the userdata and parse it, but I've just always gone off the security group, and when not sure, just start asking everyone :)
[12:23] <thumper> I'll read in the morning
[12:23]  * thumper heads to bed
[12:23] <thumper> night all
[12:23] <perrito666> jam1: will keep in mind for the future, thank you
[12:34] <wallyworld> katco: axw: mgz_: finally finished meetings, standup?
[12:34] <katco> wallyworld: omw after refreshing coffee.
[12:34] <wallyworld> kk
[12:45] <cmars> rogpeppe, no major objections, but I have a question about validating Reference to URL conversion, commented on the PR
[12:46] <rogpeppe> cmars: you can't stop it, but you also can't stop a user just setting a URL.Series to ""
[12:46] <rogpeppe> cmars: if we see people doing it, it should be an obvious smell
[12:48] <cmars> rogpeppe, malicious abuse of the API is less of a concern than unintended side effects. a conversion function could catch and prevent a class of defects when using the juju APIs
[12:48] <rogpeppe> cmars: if we really wanted to, we could make both URL and Reference opaque (and incompatible) types, but that would be a much bigger change, and i honestly don't think the payoff is worth it. the problem is largely theoretical AFAICS.
[12:49] <rogpeppe> cmars: we already have a conversion function
[12:49] <rogpeppe> cmars: just nothing to stop a deliberate type conversion.
[12:50] <rogpeppe> cmars: isn't doing (*charm.URL)(ref) just as much an abuse of the ABI as url.Series="" ?
[12:50] <rogpeppe> cmars: what's the worst that can happen if a series is left unspecified anyway?
[12:53] <rogpeppe> cmars: ISTM that this is similar to the "you can put the wrong constant in a typed constant" problem - yes, it's a theoretical problem, but it's not one that seems to be an issue in practice.
[12:53] <rogpeppe> cmars: also, it's easy to statically check for type conversions like this
[12:54] <cmars> rogpeppe, how would you check for them? just curious
[12:55] <rogpeppe> cmars: it'd be easy enough to write a little go program that used go/types (that would guarantee 100%) but just a grep for '\(\*charm\.URL\)\(' would be pretty close, given gofmt'd code
[13:03] <perrito666> say I found a bug and I already know the fix, do I need to also create the bug in launchpad?
[13:03] <perrito666> or can I just send the fix with the explanation
[13:04] <rogpeppe> perrito666: i'd do the latter. but perhaps i'm just lazy :-)
[13:04] <natefinch> perrito666: usually filing a bug is a good idea so that if someone comes from an older release and complains about the bug, we can know it's fixed in the current releasre
[13:04] <rogpeppe> perrito666: although, perhaps best to add the bug, because of what natefinch says
[13:04] <perrito666> rogpeppe: yeh, he is the boss in my case :p
[13:04] <perrito666> so if he says jum, I ask how far
[13:04] <rogpeppe> totally trivial PR for review, please: https://github.com/juju/txn/pull/6/files
[13:05] <cmars> rogpeppe, thanks. i think i'm ok with the types. still going over other aspects of the change. need some coffee :)
[13:05] <rogpeppe> (one line change with no semantic implication)
[13:05] <rogpeppe> cmars: cool.
[13:06] <natefinch> anyone know how to manually update something in juju's db?  I need to set one property in a user's deployment that mgo doesn't support, so ideally I'd just go in and set it by hand.... but without the javascript console, I'm not sure if that's possible
[13:07] <rogpeppe> natefinch: what property is that?
[13:07] <rogpeppe> natefinch: also, why don't you have a js comsole?
[13:07] <perrito666> natefinch: just use the mongo cli
[13:07] <perrito666> rogpeppe: not installed by default
[13:08] <sinzui> wallyworld, axw. Sorry 1.20 appears to be broken. the precise unit tests fail, precise deployments error, because there is no mongo
[13:08] <natefinch> rogpeppe: the juju-mongodb doesn't have javascript support, I figured that would prevent us from being able to log in and just issue javascript commands
[13:08]  * sinzui reports bug
[13:08] <wallyworld> sinzui: hang on a se c
[13:08] <wallyworld> sinzui: it is fixed, but CI is a couple of revisions behind
[13:08] <rogpeppe> natefinch: i *think* most of the js runs client-side
[13:08] <sinzui> wallyworld, \o/
[13:08] <wallyworld> sinzui: i was worried too but i checked the revisons
[13:09] <wallyworld> sinzui: i also live tested tip of 1.20 on ec2
[13:09] <rogpeppe> natefinch: i've not had a problem using the js console on the juju db
[13:09] <natefinch> rogpeppe: the property is the readonly property on a user
[13:09] <natefinch> rogpeppe: ok, cool
[13:09] <wallyworld> sinzui: CI was *2* revisions behind, so this next run may fail also
[13:09] <sinzui> wallyworld, I see archive issues in some of the unit-test runs. I am trying a newer ami too
[13:09] <rogpeppe> natefinch: mgo has a few back doors you can usually do stuff through
[13:10] <wallyworld> sinzui: rev 1cd26425cac98adc4e9aa70efa4e23b70f026c1d is the good one
[13:10] <sinzui> wallyworld, it will fail, it is getting the mongo error at the moment. I wont panic
[13:10] <sinzui> noted, thank you wallyworld
[13:10] <wallyworld> ok, i oaniced :-)
[13:10] <rogpeppe> natefinch: e.g. http://godoc.org/labix.org/v2/mgo#Session.Run
[13:10] <wallyworld> panicked
[13:10] <wallyworld> np
[13:10] <natefinch> rogpeppe: yeah, ideally I wouldn't have to write code, just run a quick javascript command through the mongo cli
[13:10] <rogpeppe> natefinch: have you tried it?
[13:10] <wallyworld> sinzui: i was going to contact you but i only *just* finished all my meetings
[13:11] <natefinch> rogpeppe: not yet
[13:11] <rogpeppe> natefinch: worth doing, i think
[13:11] <sinzui> wallyworld, np, I was only 20 minutes into the investigation
[13:11] <wallyworld> sorry
[13:12] <natefinch> rogpeppe: the issue is that hackedbellini has a server in a really unusual bad state of being half-upgraded from 1.19 to 1.20, and he gets an error when trying to update the admin password saying the entry must not have both a roles field and a readonly field
[13:12] <rogpeppe> natefinch: marvellous
[13:12] <natefinch> he's the one with the server that somehow managed to upgrade from 1.18 to 1.19, even though that shouldn't be possible
[13:13] <natefinch> so we're trying to get him upgraded to 1.20
[13:13] <natefinch> This is the current error that is blocking the upgrade - mongo returns "system.users entry must not have both 'roles' and 'readOnly' fields"
[13:14] <natefinch> when we try to set the admin password.  We should probably fix it in code, but I'm super busy right now, so I was hoping to give him a quick javascript command to run that would unblock him by removing the readOnly field
[13:15] <natefinch> brb
[13:16] <cmars> jam1, can you PTAL at my login API versioning branch, just rebased against master, https://github.com/juju/juju/pull/392
[13:16] <hackedbellini> rogpeppe: yes, we were affected by this issue: https://bugs.launchpad.net/juju-core/+bug/1325034 (it was actually my boss who opened it)
[13:16] <_mup_> Bug #1325034: juju upgrade-juju on 1.18.3 upgraded my agents to 1.19.2 <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1325034>
[13:16] <hackedbellini> Then we tried upgrading from 1.19 to 1.20 and we had a problem because the installation was missing HA
[13:16] <hackedbellini> thumper said to me to try to change the agent.conf to read "upgradedToVersion: 1.18.4" so it would do the HA setup (that appears to only be triggered in the 1.18 => 1.20 migration and not the 1.19 => 1.20)
[13:16] <hackedbellini> by doing that we hit that other issue natefinch described
[13:16] <rogpeppe> hackedbellini: good luck :-)
[13:16] <perrito666> gsamfira: ping
[13:24] <natefinch> back
[13:26] <natefinch> rogpeppe: how do I get the password to use to log into mongo in an existing environment?
[13:27] <rogpeppe> natefinch: from a machine agent config file
[13:27] <natefinch> rogpeppe: ahh ok
[13:31] <gsamfira> perrito666: pong
[13:31] <perrito666> natefinch: statepassword iirc in /var/lib/juju/agents/machine-0/agent.conf
[13:32] <marcoceppi> How do I create a subordinate in a core test? I've tracked down a few examples but the entire testing side of the core project is quite mysterious. if someone had a few moments to help me out that'd be awesome
[13:37] <rogpeppe> cmars: are you still reviewing?
[13:43] <fwereade> marcoceppi, heyhey
[13:43] <marcoceppi> o/
[13:44] <fwereade> marcoceppi, it can indeed be a bit of a hassle, but give me a sec and I'll try to find you an example at a suitable level
[13:44] <voidspace> rebooting to (hopefully) fix some odd test failures that I think are due to machine load
[13:45] <marcoceppi> fwereade: that would be awesome. I understand this entire part of the test. Just no idea how to s.AddTestingSubordinateCharm()
[13:45] <marcoceppi> or whatever the method name will be
[13:45] <marcoceppi> I guess it would be AddTestingCharm, then s.State.AddSubordinateService or something such
[13:46] <fwereade> marcoceppi, in short you have to do all the steps manually: ie add a subordinate charm, create a service, add a relation with the principal service, and then have the principal unit enter scope
[13:46] <fwereade> marcoceppi, see TestDestroySubordinateUnits in client_test.go
[13:47] <marcoceppi> fwereade: so I found something like that in another module of the project
[13:47] <marcoceppi> fwereade: ack, will look! Thanks
[13:48] <ericsnow> fwereade: thanks for the review...it's really helpful :)
[13:49] <fwereade> marcoceppi, if you feel like being awesome, you could take a look at testing/factory and add a MakeSubordinate method :)
[13:49] <fwereade> ericsnow, cool
[13:49]  * marcoceppi scratches chin
[13:49] <marcoceppi> well I do like being awesome
[13:50] <fwereade> ericsnow, if there's anything that bears discussion let me know and we can hangout
[13:50] <ericsnow> fwereade: I keep forgetting that I'm only about a meter below the waterline while chipping at the iceberg that is juju
[13:51] <fwereade> ericsnow, yeah, there's an awful lot to take in I'm afraid
[13:52] <ericsnow> fwereade: menno also gave me some good feedback last night before I went to bed
[13:52] <fwereade> ericsnow, excellent
[13:53] <rogpeppe> fwereade: any chance you might be able to take a look at https://github.com/juju/charm/pull/31 ?
[13:54] <ericsnow> fwereade: will you have some time to chat in a little while (I have standup soon)?
[14:01] <fwereade> ericsnow, sure, just ping me when you're free
[14:02] <ericsnow> fwereade: will do, thanks
[14:02] <mattyw> fwereade, I'm going to put something in the diary for a little talk with green squad if that's ok? probably after the next sprint
[14:02] <perrito666> natefinch: stand up?
[14:02] <mattyw> fwereade, unless you have spare time tomorrow
[14:04] <natefinch> perrito666: coming
[14:04] <fwereade> mattyw, I should be able to do tomorrow
[14:04] <fwereade> mattyw, morning would be better than afternoon I think, my time sense is still a bit messed up and I start feeling a bit sleepy and useless at lunchtime
[14:05] <mattyw> fwereade, welome to my life
[14:17] <mattyw> fwereade, just sent an intivte, probably won't take an hour
[14:45] <ericsnow> fwereade: you available?
[14:45] <fwereade> ericsnow, sure, 5 mins?
[14:46] <ericsnow> fwereade: sounds good
[14:55] <perrito666> rogpeppe: have a sec?
[14:56] <rogpeppe> perrito666: i have a meeting in 4 minutes
[14:56] <rogpeppe> perrito666: but if you make it fast... :-)
[14:56] <perrito666> rogpeppe: ok, ill try
[14:56] <perrito666> I made as you know a tar/untar wrapper which works very well except when untaring symlinks
[14:57] <wwitzel3> trying build juju-1.19.3 and I'm getting launchpad.net/juju-core/testing/testbase cannot find pacakge
[14:57] <wwitzel3> godeps -f -u is running cleanly
[14:58] <rogpeppe> wwitzel3: perhaps dependencies.tsv hasn't been updated
[14:58] <perrito666> do you happen to know where is the link stored in the header? I get a fileinfo struct and I am pretty sure its in the Sys() struct but I haven't looked at it yet
[14:59] <rogpeppe> perrito666: isn't it in Header.Linkname ?
[15:00] <perrito666> rogpeppe: aghh, I was looking at the wrong place, thank you again
[15:00] <rogpeppe> perrito666: np :-)
[15:01] <wwitzel3> rogpeppe: I checked out to the 1.19.3 tag, I assume that the dependencies.tsv would of been updated accordingly when that tag was commited.
[15:02] <rogpeppe> wwitzel3: worth checking
[15:03] <wwitzel3> rogpeppe: I have no idea what I'm looking for .. I have no clue what version of juju-core/testing 1.19.3 is supposed to be pinned on.
[15:03] <wwitzel3> rogpeppe: or should I be building 1.19.3 from launchpad and not github?
[15:03] <rogpeppe> wwitzel3: i don't know, i'm afraid
[15:03] <rogpeppe> wwitzel3: perhaps sinzui or mgz would be more help
[15:03] <wwitzel3> thanks :)
[15:04] <sinzui> wallyworld, no, but I cannot prove it
[15:05] <hackedbellini> natefinch: any news?
[15:05] <sinzui> wwitzel3, interesting question
[15:05] <marcoceppi> is there any formatting guidelines for core? like 80-col wrap, etc?
[15:05] <sinzui> wwitzel3, while tags were not migrated to github, we can add the tags we need.
[15:06]  * marcoceppi just found go fmt
[15:06] <sinzui> wwitzel3, do you want the tag, or do you just want to see what the deps were for the release?
[15:06] <wwitzel3> sinzui: well my issue was that there is a 1.19.3 tag, but checking that out, running godeps, and attempting to build results in some package not found errors.
[15:06] <sinzui> wwitzel3, I think developers moved packages again.
[15:06] <wwitzel3> sinzui: refercing juju-core/testing/testbase which is a package that doesn't exist anymore I think.
[15:07] <sinzui> wwitzel3, When CI find the problem in a test, we ask that the package be put back...obviously we have not tested 1.19.3 in 2 months
[15:07] <wwitzel3> sinzui: but I answered my own question, if there is a 1.19.3 in lp, I will just build it from there.
[15:07] <natefinch> hackedbellini: I'm handing you off to wwitzel3.  He'll take care of you.
[15:08] <wwitzel3> sinzui: yeah, I understand, I'm just trying to replicate the environment that hackedbellini's has
[15:08] <wwitzel3> sinzui: so was trying to get a local provider up and running with 1.19.3
[15:08] <sinzui> wwitzel3, maybe you want the tarball that was that release?
[15:08] <wwitzel3> sinzui: seems like a good solution :)
[15:09] <sinzui> wwitzel3, This is the release https://launchpad.net/juju-core/+milestone/1.19.3
[15:10] <sinzui> wwitzel3, I just checked github/lp . 1.19.3 is only in github, even if it was in  Lp, the packages would be moved. I think the tarball or deb is the way to get what the user has
[15:11] <natefinch> hackedbellini: wwitzel3 is taking care of you
[15:11] <natefinch> hackedbellini: I had to hand you off because I got assigned some critical work.  Wayne will get it sorted out for you, though.
[15:12] <natefinch> hackedbellini: and he's less busy than me, so he's less likely to make you wait
[15:32] <rogpeppe> cmars: gentle nudge about https://github.com/juju/charm/pull/31
[15:33] <sinzui> 1.20.2 has a new regression in precise unit tests. I am looking for a common cause of the failure https://bugs.launchpad.net/juju-core/+bug/1350911
[15:33] <_mup_> Bug #1350911: precise unit-tests fail in 1.20 <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1350911>
[15:47] <bodie_> https://github.com/juju/juju/pull/448 re. davecheney getting out-of-order Actions failing the apiserver test
[15:47] <bodie_> very simple test fix to include a map which counts appearances instead of expecting actions in a specific order
[15:48] <bodie_> +27, -9
[15:51] <wwitzel3> when I deploy with local provider, why don't the containers show up in lxc-ls?
[15:55] <rick_h__> wwitzel3: they should
[15:55] <rick_h__> wwitzel3: sudo lxc-ls?
[15:55] <wwitzel3> rick_h__: ahh that's probably it
[15:56] <wwitzel3> rick_h__: thanks
[15:56] <bodie_> sudo all the things!
[15:56] <rick_h__> wwitzel3: np
[16:02] <bigjools> hello juju people
[16:02] <rick_h__> bigjools: party party
[16:02] <bigjools> when a provider gets asked to start a machine up, is that dine in a go routine?
[16:02] <bigjools> dine?  done
[16:05]  * bigjools going to ping devs at random now
[16:06] <natefinch> bigjools: are you asking if it's async or not?
[16:06] <bigjools> natefinch: sort of, we want to put some polling in the maas provider and noticed it already has blocking Sleep calls in it
[16:07] <bigjools> which is either great or horrifying
[16:07] <natefinch> bigjools: it's at least the latter
[16:08] <bigjools> I have few issues concurring
[16:10] <natefinch> bigjools: so, everything is done in a goroutine.... it's just a matter of which one and what else wants to get stuff done on the same goroutine
[16:13] <bigjools> natefinch: ok, so would be be ok to block the return until it acquires a machine?  And can the caller handler retries?
[16:16] <natefinch> bigjools: the maas provider just does a POST on the start endpoint... it doesn't seem to wait very long for it to return, so I presume the serverside itself is async
[16:18] <bigjools> natefinch: well I am asking about the provider here - we're changing the maas API to help with working out when an acquisition is successful, or failed.  It will need to poll an API endpoint for status.
[16:19] <bigjools> so it sounds like it's ok to just block inside a loop that Sleeps;polls;Sleeps etc.
[16:23] <hackedbellini> natefinch: no problem :)
[16:23] <hackedbellini> so, wwitzel3, will we workaround the issue today? If you are busy, we can do it next week, no problem =P. I'll be here for more 2 hours and tomorrow I won't come to work
[16:49] <jcw4> perrito666: does todays big news affect you much?
[16:50] <perrito666> jcw4: nah, I dont think general population will be affected yet, macroeconomic issues take months to show in daily life
[16:50] <jcw4> perrito666: figured, but since you'd mentioned it a few weeks ago thought I'd ask
[16:51] <perrito666> jcw4: tx man, there was some incertitude, but its like when your girlfriend tells you "we need to talk" after you talk, wether the news are good or bad, its done and everything goes back to normal :p
[16:51] <jcw4> perrito666: hahaha
[16:53] <natefinch> dammit... I just saw that Andrew submitted a fix for the windows bug that I've spent the last day fixing
[16:54] <perrito666> that happens a lot lately, we should be more vocal about what we are doing
[16:54] <perrito666> there was some of that on last night discussion
[16:54] <natefinch> My fault, I guess for not assigning the bug to myself.... I did post in response to the email about CI being blocked
[16:57] <jcw4> natefinch: so what is the process if you see a bug?  Check for bug in lp and file if it's not there, and then assign to self?
[16:57] <natefinch> jcw4: the assigning part is optional unless you want to fix it
[16:57] <jcw4> natefinch: okay
[16:58] <jcw4> so any self-initiated work to fix a bug should probably be tracked through lp then?
[16:59] <natefinch> yeah, that way if someone comes along and sees it in an older version, we know it's been fixed, and if any developer sees it at approx. the same time, you don't have two people working on it at the same time (like what happened with me)
[17:00] <jcw4> makes sense... I've avoided the bug list in lp for a while... I should probably start paying closer attention.
[17:08] <perrito666> yo might also want to do some noise here
[17:08] <jcw4> perrito666: +1
[17:08] <perrito666> so someone will most likely remember what you said when someone else asks
[17:11] <tasdomas> hi
[17:12] <tasdomas> I have a gwacl question - since it's a bit early in the day for axw, could anyone help me?
[17:16] <natefinch> maybe
[17:18] <bodie_> hmmm...  I think I just yawned a yawn to make up for the grind of the last four days.  that was great.
[17:18] <bodie_> it feels so good to see Actions firing off.
[17:51] <tasdomas> natefinch, I'm working on the port ranges task and am at the moment changing the providers to operate on port ranges
[17:51] <tasdomas> gwacl, however, does not seem to have the ability to open a range of ports at once, though
[17:52] <natefinch> tasdomas: might have to be something you add, then
[17:53] <tasdomas> natefinch, yeah, I figured that - was simply wondering if az
[17:53] <tasdomas> azure api actually supports that
[17:54] <natefinch> tasdomas: sorry, no idea. I would think so, but azure is wacky.   You'll have to look it up
[17:58] <tasdomas> natefinch, thanks
[18:02] <bodie_> hmmm, what's up with this jenkins build output? http://juju-ci.vapour.ws:8080/job/github-merge-juju/196/console
[18:03] <natefinch> bodie_: trunk is locked
[18:03] <natefinch> bodie_: the beatings will continue until morale improves
[18:05] <natefinch> bodie_:   note the comment on your PR: https://github.com/juju/juju/pull/415
[18:05] <natefinch> there's a couple blocking bugs
[18:05] <bodie_> ah
[18:06] <bodie_> natefinch, presumably to be found at LP/juju-core/bugs
[18:06] <bodie_> +bugs*
[18:06]  * perrito666 is becoming a tibetan monk while testing restore
[18:07]  * bodie_ is confused by perrito666's sense of humor
[18:08] <perrito666> bodie_: it requires to prepare a lot of things, run them and in the mean time wait
[18:08] <perrito666> and meditate
[18:13] <bodie_> perrito666, go into your mind palace like Sherlock Holmes and study the ineffable mysteries of reducing "if err != nil { return err }" statements Go :P
[18:13] <bodie_> in Go*
[18:19] <natefinch> man.... whenever I go to build something that isn't a go project, I am reminded of why go rocks so much.... there's no like 8 step process to download the code and set up the build environment and run the build.
[18:19] <rick_h__> no, just magic /.. :P
[18:20] <natefinch> there's no magic, it's all very derministic
[18:20] <natefinch> deterministic... unlike my spelling
[18:22] <natefinch> also, people who put the shell prompt in the text of their command line instructions need to be shot.  Thanks for ruining copy & paste.
[18:23] <jcw4> natefinch: don't you think shooting is a little harsh? maybe a stern talking to?
[18:23] <rick_h__> or maybe using your tools to select the copy/pasteable part?
[18:23]  * rick_h__ ducks as he always does the $ command here
[18:24]  * jcw4 too
[18:24] <natefinch> jcw4: I didn't say with what I'll shoot them
[18:24] <jcw4> heh; I'm hoping for old nerf guns
[18:24] <natefinch> something smelly and sticky
[18:24] <jcw4> :)
[18:26] <natefinch> also shooting people who put relative links in their instructions without making it perfectly clear what the directory structure should look like
[18:28] <jcw4> easy, just do: $ ln -s ../hooks/remember-absolute-paths.sh
[18:28] <perrito666> natefinch: doen't your editor support block selection?
[18:28]  * perrito666 hides
[18:28] <natefinch> perrito666: It's the browser
[18:28]  * natefinch squints at jcw4 
[18:29] <jcw4> haha
[18:29] <perrito666> natefinch: isn;t your browser your editor?
[18:29] <natefinch> https://github.com/Tokutek/mongo/blob/master/docs/building.md
[18:29]  * perrito666 waits for katco to say something
[18:29] <natefinch> perrito666: no no, katco's editor is her browser... there's a difference
[18:29] <jcw4> katco's an emacs zombie!?
[18:29] <natefinch> yep
[18:29]  * jcw4 ducks and hides
[18:31] <rick_h__> hah, thought you were saying she's using that newish github thing that's nodejs and all JS
[18:31] <natefinch> atom.io
[18:31] <jcw4> atom?  I've tried it
[18:32] <natefinch> I would if..... *drum roll*  their build instructions weren't a mile long
[18:32] <jcw4> har har har
[18:32] <natefinch> seriously: https://github.com/atom/atom/blob/master/docs/build-instructions/linux.md
[18:33]  * jcw4 wonders if natefinch knows how long a mile is
[18:35] <perrito666> OS with 64-bit or 32-bit architecture
[18:36]  * perrito666 looks suspiciously
[18:36] <perrito666> what exactly does that mean?
[18:36] <natefinch> haha
[18:37] <perrito666> like, dont do this in win 3.11?
[18:37] <natefinch> heh, I was just typing that
[18:37] <natefinch> I love installations that start with "curl this script and run it"
[18:38] <perrito666> as long as it isnt sudo curl this
[18:38] <natefinch> they didn't write sudo curl, but it doesn't work unless you sudo
[18:38] <natefinch> https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager#ubuntu-mint-elementary-os
[18:39] <perrito666> lol
[18:39] <perrito666> "Ill leave this curl here, and if you sudo it, it will be your responsability"
[18:40] <natefinch> That's also a pet peeve... if something needs sudo, just write sudo, don't assume I'm running as root like an idiot
[18:42] <perrito666> that is a bit harsh on idiots
[18:43] <natefinch> heh
[18:43] <perrito666> Idiots most likely run user 1000
[18:45] <natefinch> oh, hey, while I'm cloning crap that isn't go code... I heard a suggestion someone made a long time ago that I really like - they put all open source code in their GOPATH... even non-go code. So, like, I'm putting tokumx in $GOPATH/src/github.com/Tokutek/mongo  and atom in $GOPATH/src/github.com/atom/atom
[18:46] <jcw4> i've been doing that too... not sure yet whether or not it'll be a good idea
[18:46] <natefinch> I like it.... it means I never need to wonder where I put some code
[18:46] <jcw4> I've been able to go get non go code on github :)
[18:46] <natefinch> ha, yeah, that works
[18:46] <jcw4> I get a build error, but the repo's there
[18:47] <natefinch> it saves some typing, at least
[18:47]  * natefinch is go getting atom
[18:47] <perrito666> natefinch: lol, I nuke my GOPATH every now and then, but cant hurt to try
[18:47] <natefinch> perrito666: sacriledge
[18:48] <perrito666> natefinch: I treat my work machine storage as something ephemeral
[18:48] <natefinch> perrito666: I periodically nuke individual folders because source control doesn't always do the right thing... but I keep around most of it
[18:49] <perrito666> and I assume everything in repos to be re-fetchable or not safe to use
[18:49] <natefinch> oh yeah, definitely.... I just don't like waiting :)
[18:50] <bodie_> jcw4 must have missed the minor editor scuffle we had in here a few days ago
[18:51] <natefinch> hazmat: you around?
[18:51] <bodie_> there was nearly a discussion of the editor of the beast
[18:51] <bodie_> vi, vi, vi
[18:51] <jcw4> lol
[18:58] <TheMue> yeah, vi(m) plus my little go plugin
[18:59] <jcw4> I switched to vim a long time ago when I reasoned vi was more ubiquitous than emacs
[18:59] <jcw4> but I still wish I knew emacs a little better
[19:02] <TheMue> I’m happy with vi since my time as admin in the 90s. it’s on each system, especially during server hopping, and always is quick when opening opening files with it
[19:03] <hazmat> natefinch, yup
[19:03] <hazmat> natefinch, currently in meetings
[19:04] <hazmat> natefinch, free in 15m
[19:04] <natefinch> hazmat: ok, let's talk then.  Trying to build tokumx with ssl (I presume that's possible)
[19:04] <hazmat> natefinch, cool
[19:04] <hazmat> natefinch, i think  trunk uses cmake instead of scons
[19:04] <hazmat> of tokumx
[19:05] <natefinch> hazmat: yeah, their build instructions use cmake
[19:07] <natefinch> build warnings in production code are cute
[19:14] <wwitzel3> lol
[19:16] <natefinch> one of the very first things I did at my last job was to turn on "warnings as errors" and eliminate all warnings from the codebase.  Took a while, but... seriously, people.   Read the warnings and fix your damn code.
[19:18] <wwitzel3> natefinch: I agree, I found that warnings as errors usually resulted in my fixing things that were about to be bugs anyway
[19:19] <natefinch> yep
[19:20] <natefinch> it also makes it a lot easier to see the real errors when you don't have 500 warnings :)
[19:20] <wwitzel3> hah
[19:37] <hazmat> natefinch, got time now?
[19:37] <hazmat> i've got an 1hr till my next mtg
[19:37] <hazmat> natefinch, have you tried building mongo from src?
[19:38]  * hazmat remembers it being painful
[19:38] <hazmat> and slow
[19:42]  * perrito666 notices that his new bootstrap machine seems to lack /tmp
[19:47] <natefinch> hazmat: yeah, I built mongo from source
[19:47] <natefinch> http://askubuntu.com/questions/392664/how-do-i-build-mongodb-with-ssl-support-on-saucy
[19:50] <natefinch> hazmat: I'm trying to run juju against tokumx, but the default version doesn't have SSL, which we use
[19:50] <natefinch> hazmat: so I built from source, but I'm not sure how to build with SSL, wea hoping you'd already done that, but I guess not :)
[19:52] <natefinch> hazmat: ahh, -D USE_SSL=ON
[19:52] <hazmat> cool
[19:53] <hazmat> natefinch, i was just using mgo test suite directly against tokumx dl bins
[19:53] <hazmat> and writing txn programs against that
[19:56] <natefinch> hazmat: sounds like we're doing nicely parallel operations, so I'll keep on seeing if it really is a "drop in" replacement... even if some of the mgo tests fail
[19:57] <natefinch> parallel?  orthogonal?  one of those
[19:57] <natefinch> neither duplicating nor conflicting
[20:01] <natefinch> doh
[20:01] <natefinch> Error 2
[20:01] <natefinch> well, thanks for the informative error message :/
[20:02] <natefinch> ug, lots of build errors in code with ssl in the name :/
[20:15] <hazmat> natefinch, all dev libs installed?
[20:16] <natefinch> hazmat: I think so
[20:16] <hazmat> natefinch, mgo tests are exhaustive failure modes.. some of which i suspect are attuned to mongo's impl
[20:17] <natefinch> hazmat: yeah, I assumed the mgo tests are probably testing stuff we don't depend on.... but I figured the best way to find out is to just try it
[20:17] <hazmat> natefinch, agreed
[20:17] <natefinch> I posted to the user forums, we'll see if there's an answer
[20:17] <natefinch> https://groups.google.com/forum/#!topic/tokumx-user/KeZ_SJ_BUac
[20:18] <hazmat> natefinch, re ssl errors you have libssl-dev ?
[20:18] <natefinch> yep
[20:18] <hazmat> natefinch, cool.. i'll give it a try as well
[20:18] <hazmat> hmm
[20:19] <natefinch> I installed all the libs I listed here: http://askubuntu.com/questions/392664/how-do-i-build-mongodb-with-ssl-support-on-saucy
[20:19] <hazmat> natefinch, those look like unresolved refs to ssl includes.. and sure enough its not in their cmake lists
[20:19] <natefinch> plus they needed libpcap-dev
[20:20] <hazmat> natefinch, where do you see that?
[20:20] <natefinch> hazmat: when I built it said Could NOT find PCAP (missing:  PCAP_LIBRARY)
[20:21] <hazmat> interesting
[20:21]  * natefinch apt-get installs all the things
[20:21] <hazmat> somewhat curious why mongo (which also apparently needs it ) uses pcap
[20:22] <natefinch> hmm... I don't remember having to install it for building mongo, at least the version I built back in December
[20:22] <hazmat> natefinch, there is a cmake/FindSSL.cmake thingy
[20:22] <natefinch> but maybe I had it already
[20:22] <natefinch> for whatever reason
[20:23] <natefinch> always inspiring to have your first encounter with your database be a pull request to fix their makefile :/
[20:24] <hazmat> natefinch, have you built mongo before?
[20:24] <hazmat> oh cool
[20:24] <hazmat> i've had to custom patch it as well
[20:28] <natefinch> can you share your patch?  My make skills are about on par with my Swahili
[20:31] <natefinch> oops, didn't realize it was late already.  Gotta bail early today.  Email me the change if you can, otherwise I'll hack on it in the morning.
[20:31] <natefinch> hazmat:  ^
[20:33] <hazmat> k
[20:33] <hazmat> was in ref to mongo, in ref to tokumx it looks like you need gnutls-dev
[20:48] <arosales> any folks have the latest on where the microsoft support merge is currently at?
[21:05] <thumper> sinzui: hey
[21:05] <thumper> sinzui: the current test failure, is that just a normal test run? or something else?
[21:06] <sinzui> thumper, ci is testing 1.20. Nothing seems normal today
[21:06] <thumper> sinzui: do the devel tests fail on precise?
[21:07] <sinzui> thumper sorry, we have many regressions that affect each branch differently
[21:07]  * thumper sighs
[21:07] <sinzui> thumper, devel and stable precise unit tests are broken for different reasons :(
[21:07]  * hazmat notes nates not here.
[21:08] <hazmat> built on the first try for me
[21:09] <sinzui> thumper, I just sent an email summarizing my abdominal day. It lists 6 bugs, 5 of which are new in the last 12 hours
[21:09] <thumper> sinzui: yeah, reading it now
[21:11] <sinzui> Maybe I should have cheered that the win client works again after a 5 weeks of hate
[21:22] <stokachu> in juju 1.20.x there seems to be a delay when the environment is bootstrap and when you can actually access the state api server
[21:22] <stokachu> i get connection refused for about 4-5 seconds
[21:34] <thumper> stokachu: which provider?
[21:35] <stokachu> thumper, local provider with kvm container
[21:35] <thumper> hmm...
[21:36] <stokachu> i can create a bug with a reproducer
[21:36] <thumper> sure, why not
[21:36] <waigani> morning thumper are you still reviewing or can I push?
[21:36] <thumper> waigani: push away
[21:40] <voidspace> what's the default api port?
[21:40] <voidspace> I mean, I could look it up...
[21:40] <voidspace> 17070
[21:42] <voidspace> what's the easiest way of getting a 1.18 juju?
[21:42] <voidspace> does it involve bzr...
[21:42] <voidspace> git tags seem to start at 1.19.3
[21:42] <voidspace> to be fair that will work fine though
[21:44] <waigani> thumper: PTAL https://github.com/juju/juju/pull/437
[21:49] <wallyworld> sinzui: hi, i'm trying to understand the stale lock bug. where did you find stale locks? in /var/lib/juju/locks? did you remove files inside that dir to release the lock? the new implementation uses native flock which releases any lock held when the lock is closed or when the  process dies so i'm confused right now as to what is happening
[21:50] <sinzui> wallyworld, I do indeed need to delete those locks.
[21:50] <sinzui> wallyworld, I destroyed the env, but the lock still exists
[21:50] <wallyworld> hmm
[21:51] <sinzui> wallyworld, then when older juju runs...nothing
[21:52] <sinzui> wallyworld, I can confirm 1-2 hours passes on some of the machines where no juju processes were running
[21:52] <wallyworld> sinzui: the lock subdir inside /var/lib/juju/locks is meant to be removed when the template container is created. and even if there's a bug and it's not, when machineagent dies, it is supposed to be released since that's how flock works
[21:52] <sinzui> :(
[21:52] <wallyworld> ok, we will look into it
[21:52] <wallyworld> :-( indeed
[21:53] <wallyworld> sinzui: i've created and destroyed local provider environments several times without an issue so will be interesting to see what's happening here
[21:54] <sinzui> wallyworld, would you like to visit the i386 slave which had a lock after 3 tries?
[21:55] <wallyworld> yes please
[22:00] <stokachu> thumper, sinzui https://bugs.launchpad.net/juju-core/+bug/1351083
[22:00] <_mup_> Bug #1351083: API server inaccessible for roughly 5 seconds after bootstrap <api> <cloud-installer> <juju-core:New> <https://launchpad.net/bugs/1351083>
[22:01] <sinzui> thank you stokachu
[22:01] <stokachu> np :D
[22:02]  * thumper goes to make another coffee before he falls asleep
[22:06] <menn0> stokachu: I have a theory on that bug. Could you attach the API server logs to the ticket please?
[22:06] <stokachu> menn0, sure lemme re-run it to get a clean log
[22:07] <menn0> stokachu: I'm mainly interested in the logs from the time the machine-0 agent starts until it starts accepting API connections
[22:07] <stokachu> menn0, ok ill get that narrowed down for you
[22:08] <menn0> if the entire log isn't too big then don't bother about filtering
[22:08] <stokachu> ok
[22:09] <menn0> back in 10...
[22:12] <stokachu> menn0, ok got the log added
[22:12] <stokachu> wasn't much so attached the whole thing
[22:13] <stokachu> took about 9 seconds for the api server to become responsive
[22:17] <marcoceppi> Hey thumper: https://github.com/juju/juju/pull/447 on my phone, but could you take a look sometime?
[22:18]  * thumper looks now at marcoceppi's pr, with sticky fingers
[22:19] <marcoceppi> It's pretty small
[22:19] <marcoceppi> But has a large impact on charm testing and benchmarking
[22:21] <thumper> marcoceppi: +1
[22:21] <marcoceppi> \o/
[22:21]  * thumper was eating an almond croissant
[22:21] <thumper> to go with the second coffee
[22:23] <jcw4> Okay, I filed my first bug https://bugs.launchpad.net/juju-core/+bug/1351089
[22:23] <_mup_> Bug #1351089: Isolation failure in sshstorage test <juju-core:New> <https://launchpad.net/bugs/1351089>
[22:23] <jcw4> which is a simple test suite isolation issue
[22:24] <jcw4> however, I can fix my own case by modifying SSHStorage.Put to use >| instead of > to get around my noclobber envar
[22:24] <jcw4> and that seems like a reasonable change to me anyway.
[22:24] <jcw4> arguments against?
[22:25] <jcw4> I think we still need to fix the environment isolation for the test, but...
[22:29] <marcoceppi> thumper: so now what?
[22:29] <thumper> marcoceppi: we wait until the bot is unblocked by CI
[22:34] <marcoceppi> thumper: cool, thanks. Looking forward to doing more minor little commits
[22:34] <jcw4> per my comments above: https://github.com/juju/juju/pull/450
[22:34] <thumper> marcoceppi: yay
[22:35] <menn0> stokachu: well your bug isn't what I thought it might be. I'll add some thoughts to the ticket though.
[22:36] <stokachu> ok thanks
[22:43] <ericsnow> wallyworld: when you have a minute I have some persistence layer questions
[22:43] <wallyworld> sure
[22:43] <wallyworld> askaway
[22:45] <ericsnow> for backups I'm storing the archive in env storage and the metadata in mongo (via a new state collection)
[22:45] <ericsnow> I'm using a couple interfaces (DocStorage and FileStorage) to abstract that away from backups
[22:47] <ericsnow> however for the actual implementation in state for the "doc" side, I feel a bit dirty hijacking a collection for something that's not actually part of state (backups are only *about* state)
[22:47] <ericsnow> any thoughts on alternatives?
[22:48] <ericsnow> also, I was talking to William about the storage abstractions I introduced as well as the env storage interfaces (and implementations)
[22:49] <ericsnow> he suggested asking you what you thought about introducing a new top-level storage package to gather in the different interfaces and implementations
[22:49] <sinzui> wallyworld, thumper the azure regression in devel might also be a cloud issue. stable is azure-deploy failed too for different reasons http://juju-ci.vapour.ws:8080/job/azure-deploy-precise-amd64/2061/console
[22:49] <sinzui> wallyworld, thumper, but in both cases, azure-upgrade (bootstrap with 1.20.1) works
[22:50] <ericsnow> the relevant PR: https://github.com/juju/juju/pull/426
[22:50] <sinzui> oh, and azure-upgrade has not failed in 2 days, so newer jujus are broken
[22:51] <wallyworld> ericsnow: there's also the blobstore stuff - a blob store takes a mongo db for the collection of namespaced paths, and a mongo db for the gridfs based blob storage
[22:51] <wallyworld> ericsnow: the backups could be stored in a namespaced path "/backups/..."
[22:51] <ericsnow> wallyworld: so when did you say you're getting us a nice persistence layer abstraction? <wink>
[22:52] <wallyworld> the you'd have a BackupStorage Fascade to access then
[22:52] <wallyworld> ericsnow: that abstraction is a while away, so much spaghetti to untangle
[22:53] <ericsnow> wallyworld: yeah, I have sauce all over my fingers :)
[22:53] <wallyworld> ericsnow: so if it were me, i'd create a BackupStorage interface that holds a ManagedStorage instance
[22:54] <wallyworld> oh hang on
[22:54] <wallyworld> you want to use file storage for the backups
[22:55] <wallyworld> ok, i had thought there was talk of storing them in a separate mongo db
[22:56] <wallyworld> so we could make them available on any state server
[22:56] <wallyworld> because cloud storage is going away
[22:56] <ericsnow> wallyworld: I'm not so concerned about the file side of backups at this point
[22:56] <ericsnow> wallyworld: we can sort of the storage backend after we get backups done :)
[22:57] <wallyworld> ericsnow: yep, so a BackupStorage interface can be done and the back end swapped out later
[22:57] <ericsnow> my questions center more on storing the metadata in State and on a new top-level storage package
[22:57] <ericsnow> wallyworld: yeah, that's exactly what I did :)
[22:57] <wallyworld> ericsnow: so what we are doing with env.Storage() is actually removing that method off Environ completely
[22:58] <ericsnow> wallyworld: that's fine, but the interfaces there (and several implementations) are still useful, no?
[22:59] <wallyworld> yes, will be changing though, but if backup is already in palce, we will port it across when the time comes
[22:59] <ericsnow> wallyworld: sounds good (on that point)
[22:59] <wallyworld> i think it's ok to store backup collection in DB("juju")
[23:00] <wallyworld> although if we think there may be more metadata type collections, we could use a new db
[23:01] <ericsnow> makes sense
[23:01] <wallyworld> but since schema migrations are coming, we could just do it the easy way for now and migrate later if needed
[23:01] <ericsnow> +1
[23:02] <wallyworld> so does that answer your question?
[23:02] <ericsnow> regardless, I'm trying to do it in a way that makes it easy to switch underneath
[23:02] <ericsnow> what about a top-level storage package?
[23:03] <wallyworld> main thing is we have that BackupStorage interface in place, and if can use an environs.Storage() interface for now
[23:03] <wallyworld> what would go inthe top level storage package?
[23:03] <ericsnow> the problem is that we can't use environs.storage.Storage in backup (due to circular imports)
[23:04] <ericsnow> the storage package would basically take the storage interfaces and implementations (where applicable)  from environs
[23:05] <wallyworld> ok, I see. Storage interface used to be in environs package actually. it was moved to environs/storage to avoid circular imports
[23:06] <wallyworld> sinzui: i'll get andrew to look at the azure issue
[23:06] <ericsnow> wallyworld: unfortunately getStorage is still in environs
[23:07] <ericsnow> regardless, I worked around that problem and it probably turned out better anyway because of that :)
[23:07] <ericsnow> I guess that answers my questsions
[23:07] <ericsnow> thanks
[23:07] <wallyworld> ericsnow: maybe GetStorage() should be moved to storagepackage?
[23:08] <ericsnow> wallyworld: I'd argue it belongs under state somewhere, since you are getting a state's env storage
[23:08] <wallyworld> yeah, true
[23:09] <wallyworld> we may well introduce a top level storage package - but sort of want to do it wholistically with all uses cases in mind
[23:09] <wallyworld> so if you can get away with it as is for now, that would be great
[23:09] <ericsnow> no worries
[23:09] <wallyworld> ty
[23:09] <ericsnow> it's no blocking me or anything
[23:10] <ericsnow> I've just run into the fact that discovering storage-related stuff isn't simple
[23:10] <ericsnow> (both for file storage and "doc"/metadata  storage)
[23:35] <perrito666> is there a way to prevent a machine from upgrading?
[23:54] <menn0> super quick review for mgo import fix please: https://github.com/juju/juju/pull/451
[23:54] <menn0> perrito666: not that I can think of (without changing the code)
[23:55] <jcw4> menn0: LGTM :)
[23:55] <menn0> jcw4: cheers