[00:00] <perrito666> menn0: what is the error?
[00:00] <axw> wallyworld: did you see my last message? sorry, dodgy wifi
[00:00] <axw> axw_> "bad HTTP response" means the API server failed to find the tools locally, and failed to find them remotely
[00:00] <menn0> perrito666: some machine agents are unable to download tools for upgrade. they get a HTTP 400 error.
[00:01] <wallyworld> axw: yeah, i found where that's being generated - the sendError(400). but we need extra info
[00:01] <wallyworld> hence my earlier request for more logging
[00:01] <wallyworld> in that area
[00:01] <axw> actually hrm, it also means it found an entry in simplestreams but failed to download it
[00:01] <axw> weird
[00:01] <wallyworld> yeah
[00:04] <perrito666> menn0: mm I doubt it but you could very well try a rever tand see what happens
[00:04] <axw> perrito666: I'm pretty certain it's not your change
[00:10] <perrito666> man hot oil realy burns
[00:18] <axw> wallyworld: https://github.com/juju/juju/pull/718
[00:19] <wallyworld> looking
[00:20] <wallyworld> let's land this and see wtf is happening
[00:29] <axw> wallyworld: hmm, wtf
[00:29] <axw> there's weirdness in the simplestreams
[00:30] <axw> wallyworld: http://paste.ubuntu.com/8304581/
[00:30] <axw> is that version at the top meant to be there?
[00:30] <axw> I guess it's not actually a problem though, since it's finding the tools...
[00:32] <wallyworld> that version at the top will be used for the containing elements unless overridden. ideally we wouldn't be generating mixed streams like that
[00:49] <wallyworld> sinzui: bug 1366887 is starting to look like it's caused by that known mongo issue https://jira.mongodb.org/browse/SERVER-11807
[00:54] <axw> interesting, IBM just sent a patch to gccgo to support Linux s/390
[00:56] <perrito666> uff, sounds large review task
[01:05] <axw> wtf mate
[01:05] <axw> thumper: is this related to identity changes?
[01:05] <axw> Error details:
[01:05] <axw> invalid entity name or password
[01:05] <axw> I just upgraded from 1.20.6 to master, got that
[01:07] <perrito666> axw: I believe wtf is the stronges language I have see coming from you
[01:09] <axw> I meant, oh bother
[01:10] <perrito666> axw: you are going to go into a craziness rampage during a sprint and kill us all right?
[01:10]  * axw twitches
[01:23] <menn0> davecheney: thanks for the review. did you see my replies to https://github.com/juju/juju/pull/715 ?
[01:25] <thumper> axw: probably
[01:25] <thumper> axw: oh fuck
[01:25] <thumper> oh fuck oh fuck ...
[01:25] <thumper> heh
[01:25] <thumper> oops
[01:26] <thumper> shit shit shit shit shit...
[01:26]  * thumper thinks
[01:27] <thumper> waigani: this relates to the change we landed yesterday where the  env user is now needed for api login
[01:27] <thumper> um...
[01:27] <thumper> axw: actually, no
[01:27]  * perrito666 notices this is coprolalia day
[01:27] <thumper> axw: maybe?
[01:27] <thumper> axw: we should chat
[01:30] <thumper> axw: you'd get that error response if you tried to access the API as a client before the upgrade steps ran to add in the env user
[01:30] <axw> thumper: sorry went afk for a bit. I tried again and it worked...
[01:31] <thumper> axw: yeah, we changed auth a little yesterday
[01:31] <thumper> axw: there now needs to be an envuser in the environment
[01:31] <axw> thumper: I tried it a few times in that run, over a few minutes
[01:31] <thumper> axw: which gets added in an upgrade step
[01:31] <axw> so maybe the upgrade went pear shaped
[01:31] <axw> will collect logs if I see it again
[01:32] <thumper> cheers
[01:35] <thumper> wallyworld: are you OK if I JFDI the landing for https://github.com/juju/juju/pull/717?
[01:35] <thumper> wallyworld: at the very worst, we get more logging context for failures
[01:35] <thumper> wallyworld: at the best (?) we don't fail as much
[01:35] <wallyworld> i think that sounds ok
[01:36] <thumper> just wanted someone else to agree with me :)
[01:36] <wallyworld> scaredy cat
[01:36] <thumper> is it JFDI or __JFDI__
[01:36] <wallyworld> can't recall
[01:36] <thumper> due diligence
[01:36]  * wallyworld was yanking thumper's chain
[01:37]  * thumper consideres his chain yanked
[01:37] <thumper> wallyworld: did you remove the "retry the tests if you fail first time" in the bot?
[01:37] <wallyworld> yup
[01:39] <thumper> cool
[01:39]  * thumper goes to walk the dog and get antibiotics for sick child
[01:39]  * thumper back soon
[01:40] <perrito666> thumper: beware, dont mi those two activities
[02:11] <axw> wallyworld: getting a different error now, unexpected deletion of resource catalog entry with id "941af6aa084ab96c30440ee74d4a321761c47bc5f069b8297d387578b919e12544227eed4fc9db1eb03d978c998e33b1": resource with id "941af6aa084ab96c30440ee74d4a321761c47bc5f069b8297d387578b919e12544227eed4fc9db1eb03d978c998e33b1" not found
[02:12] <wallyworld> one sec, otp
[02:18] <wallyworld> axw: so something is deleting the same record twice, not sure without digging why
[02:18] <axw> wallyworld: in the branch, I don't remove blobs at all. blobstore must be doing that
[02:18] <axw> wallyworld: it does handle concurrent uploads to the same path right? :)
[02:18] <wallyworld> supposed to
[02:19] <wallyworld> if uses the assert txn stuff
[02:19] <wallyworld> and ref counts
[02:20] <wallyworld> axw: ah, that message is a bit misleading; it's an error doing a Get()
[02:21] <wallyworld> it's saying it tried to fetch something that wasn't there
[02:21] <axw> wallyworld: I don't think so, this is in the code that's trying to cache the tools to storage
[02:21] <axw> wallyworld: full error message:
[02:21] <axw> 2014-09-10 02:11:01 ERROR juju.apiserver tools.go:55 GET(/environment/a7aca243-c2ef-4912-883b-049182059330/tools/1.21-alpha1.1-trusty-amd64?%3Aenvuuid=a7aca243-c2ef-4912-883b-049182059330&%3Aversion=1.21-alpha1.1-trusty-amd64&) failed: error fetching tools: error caching tools: cannot store tools tarball: unexpected deletion of resource catalog entry with id "09d4e310662142df8fc5304484ca33fc5b1ab9d1e5e1fecc09cef1369227fa71aa38c63be34dca95d1c7
[02:21] <axw> 6ff6f488df64": resource with id "09d4e310662142df8fc5304484ca33fc5b1ab9d1e5e1fecc09cef1369227fa71aa38c63be34dca95d1c76ff6f488df64" not found
[02:22] <wallyworld> look in putResourceReference
[02:22] <wallyworld> it's a sanity check at the end
[02:23] <axw> yep, I see it
[02:23] <wallyworld> it could be there's a race there
[02:23] <menn0> axw: I'm getting a vet warning when I push. looks like something you did recently
[02:24] <wallyworld> maybe existingResourceId comes back as != ""
[02:24] <menn0> axw: logger.Infof("%v tools not found locally, fetching")
[02:24] <menn0> in apiserver/tools.go
[02:24] <menn0> missing arg to Infof
[02:24] <axw> menn0: sorry, was adding logging in a rush, will fix
[02:24] <menn0> axw: np
[02:25] <wallyworld> axw: how often does that error occur?
[02:25] <axw> wallyworld: that's what's tripping up CI from the looks of things
[02:26] <axw> it's occurring over and over again
[02:26] <wallyworld> hmm, ok. but it works locally for you
[02:26] <axw> 2014-09-10 02:06:33 WARNING juju.storage managedstorage.go:183 cleaning up resource catalog after failed put
[02:26] <axw> yep
[02:44] <wallyworld> axw: i might have an idea
[02:44] <axw> wallyworld: I've reproduced it locally now... not sure if it's timing related or not
[02:44] <thumper> wallyworld: agh... write error: No space left on device
[02:44] <thumper> wallyworld: for the bot
[02:44] <thumper> wallyworld: that is a try again error isn't it?
[02:44] <wallyworld> thumper: retry
[02:44] <wallyworld> yup
[02:44] <thumper> why does it happen?
[02:44] <wallyworld> it seems it could happen if a 2nd upload happens and the ref count is attempted to be updated before the first upload finishes
[02:45] <wallyworld> thumper: nfi
[02:45] <thumper> wallyworld: got a minute to talk through a failure?
[02:45] <thumper> looking at the port in use one
[02:45] <wallyworld> thumper: sure, give me a sec
[02:45] <axw> wallyworld: can you point at code in blobstore?
[02:46] <wallyworld> axw: putResourceReference
[02:46] <wallyworld> 	// Sanity check - ensure resource catalog entry for resourceId still exists.
[02:46] <wallyworld> 	_, err = ms.resourceCatalog.Get(resourceId)
[02:46] <wallyworld> if the blob is still being uploaded, that Get() will fail
[02:46] <axw> wallyworld: ah, because pending
[02:47] <axw> right?
[02:47] <wallyworld> so if it's the 2nd caller, it's suposed to +1 to ref count
[02:47] <wallyworld> ye
[02:47] <wallyworld> p
[02:47] <wallyworld> but if 2nd caller occurs before upload is done, then boom
[02:47] <wallyworld> i think
[02:47] <axw> wallyworld: so we should only error if err != nil && err != ErrUploadPending
[02:48] <wallyworld> i think so, let me take one more look
[02:48] <axw> though I suppose PutForEnvironment shouldn't really return nil if it's pending still...
[02:49] <wallyworld> yeah, i think for now, if err != nil && err != ErrUploadPending should do it
[02:50] <wallyworld> axw: if you can reproduce, can you try that fix?
[02:50] <axw> wallyworld: I'll have a play with it
[02:50] <wallyworld> ty
[02:50] <wallyworld> thumper: did you want to talk now?
[02:51] <thumper> wallyworld: just on with menn0, shortly?
[02:51] <wallyworld> sure
[03:08] <wwitzel3> waigani: I'm confused, didn't you tell me to delete that comment?
[03:08] <waigani> wwitzel3: which one?
[03:08] <wwitzel3> waigani: the RunCommandsArgs
[03:09] <wwitzel3> waigani: also thanks for the review :)
[03:10] <waigani> wwitzel3: If I did it was a mistake, exported types should always have comments
[03:10] <waigani> wwitzel3: I'm just trying to see if/where I said that ?!
[03:12] <waigani> wwitzel3: btw a lot of the error cases are not covered by tests, but often the error states are from funcs/packages that have already been covered. But just as a suggestion maybe think if any new functions you've introduced need to be tested for expected behaviour when they crap out.
[03:19] <wwitzel3> waigani: ok
[03:19] <wwitzel3> waigani: thanks :)
[03:20] <waigani> np
[03:25] <thumper> wallyworld_: onyx hangout?
[03:25] <wallyworld_> ok
[03:36] <waigani> davecheney: do we have a rule on underscores in var names?
[03:36] <waigani> davecheney: I haven't seen them in juju, but a PR uses them
[03:40] <thumper> wallyworld_: https://github.com/juju/juju/pull/720
[03:40] <davecheney> waigani: you know i'm not a big fan of rules
[03:40] <davecheney> i'm more into shouting and throwing my weight around
[03:40] <waigani> lol
[03:41] <davecheney> this_isnt_considered_kosher()
[03:41] <davecheney> butThisIs()
[03:41] <davecheney> is all i know
[03:41] <waigani> okay, I'll s/rule/tend to
[03:42] <waigani> davecheney: I stand corrected: format_1_18Suite
[03:44] <thumper> waigani:  plx fix - http://paste.ubuntu.com/8305704/
[03:44] <thumper> waigani: pls fix - http://paste.ubuntu.com/8305704/
[03:44] <thumper> waigani: should be "equal(now) || after(now)"
[03:44] <axw> wallyworld_: https://github.com/juju/blobstore/pull/15
[03:45] <wallyworld_> looking
[03:45] <waigani> thumper: is that trunk?
[03:45] <thumper> waigani: yes
[03:45] <thumper> waigani: slipped through
[03:45] <waigani> yikes, on it
[03:45] <thumper> waigani: just hit it landing a branch, ta
[03:50] <wallyworld_> axw: thanks for fixing that, if tests pass i'll merge
[03:50] <axw> wallyworld_: they do, I'm just going to test in juju now...
[03:51] <wallyworld_> ok
[03:51] <wallyworld_> let me know and i'll merge then
[03:51] <axw> wallyworld_: do you think it would be prudent to use a different path in storage when uploading tools? e.g. generate a UUID to add to the path
[03:52] <axw> I'd rather not, seems like blobstore should be doing this
[03:52] <wallyworld_> axw: you mean and then make them available at the right path when done?
[03:53] <axw> wallyworld_: actually... I don't think the path matters does it. the resource catalog entry is based on the hash of the content, riught?
[03:53] <wallyworld_> yep
[03:53] <waigani> thumper: https://github.com/juju/juju/pull/721
[03:57] <axw> wallyworld_: juju likes that better
[03:57] <axw> it still surfaces ErrUploadPending, but it recovers
[03:57] <axw> i.e. the upgrading agent bounces and tries again
[03:58] <wallyworld_> axw: that's good enough for now :-)
[03:58] <wallyworld_> that pending thing should be fixed in the blob store i agree
[03:58] <wallyworld_> it just wasn't implemented
[04:00] <waigani> thumper: searched, found one other place, updated.
[04:01] <waigani> thumper: merge?
[04:02] <axw> wallyworld_: https://github.com/juju/juju/pull/722 please
[04:02] <axw> anyone actually
[04:05] <axw> thanks waigani
[04:05] <waigani> axw: that was a big one!
[04:06] <axw> I know, it's a hard life :(
[04:08] <jam> wwitzel3: shouldn't you be asleep around now ? :)
[04:09] <wallyworld_> axw: sorry, lost my network again right when i saw your PR
[04:14] <thumper> boo... hiss... FAIL: firewaller_test.go:460: FirewallerSuite.TestRemoveMultipleServices
[04:15] <thumper> new intermittently failing test
[04:15]  * thumper hasn't had much luck landing this branch
[04:18] <axw> wallyworld_: no worries
[04:32] <menn0> thumper: regarding our earlier conversion regarding clearing the upgradeinfo doc... it will mean a pre 1.21 client won't be able to clear it. only newer clients will have the client side support to sort out a problem
[04:32] <menn0> thumper: does that matter?
[04:33] <thumper> menn0: I don't think so
[04:33] <menn0> thumper: good. that's what I was thinking too but thought I'd better check
[04:43] <thumper> davecheney, waigani: here is the user tag branch - https://github.com/juju/juju/pull/723
[04:43] <thumper> davecheney: I'd like you to look, but perhaps as a mentor for waigani
[04:44] <thumper> wallyworld_: how do I check the landing bot status?
[04:44] <wallyworld_> http://reports.vapour.ws/ i think
[04:45] <wallyworld_> h, maybe not
[04:45] <wallyworld_> it should accept new jobs as soon as the blocker is marked fit comitted
[04:46] <thumper> bad-record-mac ... again
[04:46]  * thumper head desks
[04:46] <thumper> I think I'm approaching a record again
[04:46] <wallyworld_> thumper: oh, you want to look at your job?
[04:46] <wallyworld_> http://juju-ci.vapour.ws:8080/job/github-merge-juju/
[04:47] <wallyworld_> click on the dot next toy yours to see console output
[04:47] <thumper> ah
[04:47] <thumper> ta
[04:47] <wallyworld_> the sooner we move to mongo 2.6, the better
[04:48] <thumper> true that
[04:52] <davecheney> thumper: AAAAAAAAAAAAARGH
[04:53] <davecheney> params.Status is SO INCIDIOUS
[04:53] <davecheney> there is an interface defined in state which reuqires a params.Status
[04:53] <davecheney> they joined like simaese twins
[05:02] <thumper> ick
[05:02] <thumper> wallyworld_: success finally \o/
[05:02] <wallyworld_> \o/
[05:02] <menn0> davecheney: so is the spelling of insidious
[05:02]  * menn0 ducks
[05:07] <davecheney> har har
[05:07] <davecheney> i'm useless without the little red line
[05:07] <menn0> sorry :)
[05:07] <davecheney> menn0: anyway, back at the pooit
[05:07] <davecheney> i don't know how to undo this
[05:07] <menn0> yeah the actual point sucks
[05:07] <davecheney> we have types in the apiserver that have to implment the state.StatusSetter interface
[05:08] <davecheney> and that StatusSetter interface depends on types in   the apiserver/params package
[05:08] <davecheney> i've just stashed a whole buttload of changes
[05:08] <davecheney> and i'm going to see what happens if I move state.StatusSetter to the apiserver
[05:08] <davecheney> as it's really the api that presents that interface now
[05:08] <davecheney> nobody gets to talk to the state server directly anymore
[05:09] <davecheney> so that fact that state implements that interface is tangental
[05:11] <davecheney> menn0: does that sound sane ?
[05:11] <davecheney> state doesn't need to implement StatusSetter as that is an api method now, not a state method
[05:11]  * davecheney waves hands furiously
[05:21] <davecheney> uh, why is there an apisever/client package
[05:21] <davecheney> how is that not
[05:21] <davecheney> api/ ??!
[05:23] <thumper> davecheney: I think that is the server side part of the client (read CLI) facade
[05:23] <thumper> as opposed to worker facades
[05:24] <davecheney> o_O
[05:25] <davecheney> no, wait
[05:25] <davecheney>     _   /|
[05:25] <davecheney>     \'o.O'
[05:25] <davecheney>     =(___)=
[05:25] <davecheney>        U
[05:25] <davecheney> ACK!
[05:29] <davecheney> go test here/goes/nothin
[05:32] <wwitzel3> jam: yeah, probably, sometimes it is just more productive late at night :)
[05:37] <urulama> wallyworld_: ping
[05:37] <urulama> wallyworld_: did you get my e-mail?
[05:37] <jam> wwitzel3: I just remember you also waking up at 5am...
[05:37] <wallyworld_> urulama: hi, um, not sure, when did yuo send?
[05:37] <urulama> wallyworld_: 10min ago
[05:38] <wallyworld_> urulama: ah, you are uros
[05:38] <wallyworld_> yes, and i just replied :-)
[05:38] <wwitzel3> jam: yeah, it is more like 7 now, since no one on my team is around at 5 anymore.
[05:38] <wwitzel3> so even if I don't get to bed until 2, I still get a solid 5 hours
[05:38] <jam> wwitzel3: I'm not sure if 5 can be considered "solid", but if it is enough for you
[05:39] <urulama> wallyworld_: great, saw that PR for the fix in the e-mails, yes. thanks
[05:39] <wallyworld_> urulama: i copied william so he's in the loop about the use of env namespace
[05:41] <wwitzel3> jam: generally more is better, I really just mean it is better than 3
[05:43] <urulama> wallyworld_: ok, i'll do that as well in the future
[05:49] <axw> wallyworld_: are you still doing something with https://github.com/juju/juju/pull/714 ?
[05:51] <axw> wallyworld_: are you still doing something with https://github.com/juju/juju/pull/714 ?
[05:52] <davecheney> i made gocheck panic, do I get a prize ?
[05:52] <wwitzel3> you probably should
[05:53] <wallyworld_> axw: i wasn't going to because it just reduces the spam, rather than eliminating it. i did test my solution and it worked, but didn't seem worth it
[05:53] <wallyworld_> i should close the pr i guess
[05:53] <axw> ok. it will be less spammy in 1.21 anyway
[05:53] <axw> yes please
[05:53] <wallyworld_> yeah
[05:54] <wallyworld_> axw: i was procrastinating as to whether tp proceed or not
[05:54] <axw> nps, just wondering what to review next
[06:02] <davecheney> aaaaaaaaaaaaand, kaboom
[06:02] <davecheney> func (s *BoolSuite) TestNonBooleanValues(c *gc.C) { c.Assert(nil, jc.IsFalse)
[06:02] <davecheney> }
[06:07] <davecheney> oh no, and other tests depend on this behavior
[06:09] <davecheney> axw: wallyworld_ can you do
[06:09] <davecheney> go test github.com/juju/testing/checkers
[06:09] <davecheney> for me
[06:09] <davecheney> i think the test suite is broken
[06:09] <axw> sure
[06:10] <axw> davecheney: what commit are you on?
[06:10] <davecheney> commit 503e61bd033592d7b6003174389f68454deb7b7a
[06:10] <davecheney> Merge: 9f90119 ed4eedd
[06:10] <davecheney> Author: Andrew Wilkins <axwalk@gmail.com>
[06:10] <davecheney> yup, still broken at tip
[06:11] <axw> davecheney: works for me
[06:11] <davecheney> ooops
[06:11] <wallyworld_> me too
[06:11] <davecheney> sorry lads
[06:11] <davecheney> PEBKAC
[06:11] <axw> nps
[06:11] <davecheney> i had local changes
[06:11] <davecheney> thanks for confirming
[06:11] <wallyworld_> happens to the best of us, and tim :-)
[06:12]  * davecheney rimshot
[06:12] <davecheney> while i have you pity
[06:12] <davecheney> does anyone know if there is a c.Check check that does not mark the build as failued
[06:12] <davecheney> failure
[06:12] <davecheney> basically, I need to write a check that will fail
[06:12] <wallyworld_> hmmm, not sure
[06:13] <davecheney> but it should fail, not panic
[06:13] <davecheney> maybe I can use c.Panics or something
[06:13] <davecheney> c.Assert(nil, jc.IsFalse)
[06:13] <davecheney> ^ this panics
[06:13] <wallyworld_> isn't that what Check does:
[06:13] <wallyworld_> ?
[06:13] <davecheney> i have a fix, but can't write a test
[06:14] <jam> davecheney: c.Check(func(), gc.PanicMatches("text"))
[06:14] <davecheney> maybe I can just call the checker direclty
[06:14] <davecheney> jam:  the problem is c.Assert(nil, jc.IsFalse)
[06:14] <davecheney> panics gocheck
[06:14] <davecheney> but thereis no value of nil that will ever be jc.Istrue
[06:14] <jam> davecheney: c.Check(func() {c.Assert(nil, jc.IsFalse}, PanicMatches()) ?
[06:14] <davecheney> jam: thanks, will try
[06:14] <jam> or you don't want it to panic, but to just assert false
[06:15] <davecheney> well, nil is neither false nor true
[06:15] <davecheney> so we can't evne write nil, gc.Not(jc.False)
[06:15] <davecheney> maybe I should just call the checker directly
[06:15] <davecheney> so even if the checker doesn't panic
[06:15] <davecheney> it will still mark the test as a fail
[06:16] <jam> to be pedantic, gc.Not(jc.False) != jc.True, exactly because of stuff like nil (or a digit, or string, etc). I don't really know what the expectation is for jc.IsFalse, but I personally would expect it to fail the assert if it got nil
[06:18] <davecheney> hmm, bool_test.go:42: c.Assert(nil, jc.IsFalse)
[06:18] <davecheney> ... obtained = nil
[06:18] <davecheney> ... expected type bool, received <invalid Value>
[06:18] <davecheney> ths is the problem
[06:18] <davecheney> i have to test this
[06:20] <davecheney> sod it, i'll just call the checker directly
[06:26] <davecheney> https://github.com/juju/testing/pull/34
[06:26] <davecheney> jam: https://github.com/juju/testing/pull/34
[06:26] <davecheney> i was making it way to hard for myself
[06:30] <jam> davecheney: lgtm
[06:30] <davecheney> jam: ta
[06:31] <davecheney> now back to what is _was_ doing
[07:44] <mattyw> morning all
[07:57] <dimitern> mattyw, morning
[07:58] <menn0> anyone know why merges are still blocked? The 2 blockers that are currently in place are marked as "Fix Committed"
[08:12] <rogpeppe> menn0: ping
[08:13] <menn0> rogpeppe: pong
[08:13] <rogpeppe> menn0: just looking at https://codereview.appspot.com/92560043/
[08:14] <menn0> rogpeppe: really? that's from over 3 months ago
[08:14] <rogpeppe> menn0: wondering if there was a particular reason for disallowing a leading digit in user names there
[08:14] <menn0> right
[08:14]  * menn0 reads
[08:14] <rogpeppe> menn0: the issue was raised as to why we don't allow leading digits in user names when launchpad does allow them
[08:15] <rogpeppe> menn0: and it looks like that CL was when the change was introduced
[08:15] <rogpeppe> menn0: (before then, we did allow leading digits)
[08:15] <menn0> I'm pretty sure the regex has changed again since that PR
[08:15] <menn0> but I see it still doesn't allow leading digits
[08:16] <rogpeppe> menn0: right
[08:16] <menn0> I know there was talk at one point about making juju accept whatever LP does
[08:16] <menn0> I think someone looked at LP's code
[08:17] <menn0> but clearly we don't have exact parity
[08:17] <rogpeppe> menn0: clearly :-)
[08:17] <menn0> I don't think there's any particularly good reason but I haven't been too involved with this work
[08:17] <menn0> thumper and waigani are the best ppl to talk to
[08:18] <rogpeppe> menn0: ok, thanks
[08:18] <menn0> I don't think you'll find much argument if this needs to be changed
[08:18] <menn0> who raised the issue?
[08:55] <jam> dimitern: voidspace: TheMue: I'm probably going to miss the standup today, my son's b-day party at school got moved to the end of the school day.
[08:56] <voidspace> jam: ok
[08:56] <TheMue> jam: ok, won't wonder then
[08:56] <TheMue> jam: have fun and grats to your son
[08:57] <dimitern> jam, sure, have fun! :)
[09:40] <voidspace> jam: TheMue: dimitern: I have a doctors appointment tomorrow morning - vaccinations for India - so I'll be a bit late starting
[09:41] <voidspace> jam: TheMue: dimitern: back in plenty of time for standup though
[09:41] <TheMue> voidspace: ah, ok, some vaccinations? had it once I gave talks in India too.
[09:42] <TheMue> voidspace: but it has been a fantastic trip, I liked it.
[09:42] <dimitern> voidspace, no worries
[09:44]  * TheMue remembers the fantastic food there
[10:14] <davecheney> voidspace: im going to india next feb
[10:14] <davecheney> what vaccinations do I need ?
[10:18] <tasdomas> dimitern, ping?
[10:19] <voidspace> davecheney: ah
[10:19] <dimitern> tasdomas, hey
[10:19] <voidspace> davecheney: heh, I'll tell you when I come back from the doctors
[10:19] <davecheney> voidspace: right, brimming over with confidence
[10:19] <voidspace> davecheney: they did tell me a few weeks ago what they would do to me
[10:19] <voidspace> davecheney: but I've forgotten
[10:19] <voidspace> davecheney: it does depend where in India you're going - I'm going to Bangalore
[10:19] <voidspace> davecheney: where are you going?
[10:19] <tasdomas> dimitern, the bug you assigned to me - what version of juju did you experience this with?
[10:20] <davecheney> voidspace: same, bangaloe
[10:20] <voidspace> davecheney: I'll let you know tomorrow then :-)
[10:20] <voidspace> It was four injections IIRC
[10:21] <dimitern> tasdomas, sorry, which one?
[10:21] <davecheney>  go tool 7l a.7 m.7
[10:21] <dimitern> tasdomas, I'm going over your port ranges handover document and reassigning the bugs to myself
[10:21] <davecheney> splendid
[10:22] <tasdomas> dimitern, ah, ok
[10:22] <dimitern> tasdomas, the one I reassigned back to you is https://bugs.launchpad.net/juju-core/+bug/1359837 I believe, a fix for which landed with your PR #667
[10:22] <mup> Bug #1359837: expose open_port fails with no-op change <expose> <regression> <juju-core:Fix Committed by tasdomas> <postgresql (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1359837>
[10:22] <tasdomas> dimitern - I was talking about the postgresql on local provider one
[10:22] <tasdomas> dimitern, yes
[10:23] <dimitern> tasdomas, yes, it's not exactly about postgres, but heh :)
[10:23] <tasdomas> dimitern, yeah - I know
[10:26] <dimitern> tasdomas, thanks for the writeup btw - I managed to get into what's going on quickly
[10:26] <tasdomas> dimitern, if you have any questions - ping me
[10:27] <dimitern> tasdomas, sure, np
[10:28] <dimitern> tasdomas, my plan so far is to take your https://github.com/juju/juju/pull/517 and split it as suggested to re-propose it; then to continue with the https://github.com/tasdomas/juju/tree/port-ranges-relation-specific-port-ranges branch you started
[10:30] <dimitern> tasdomas, also, when you have some time, can you please have a look at the port ranges status doc and confirm I haven't missed a relevant filed bug?
[10:31] <tasdomas> dimitern, I will
[10:31] <dimitern> tasdomas, cheers
[10:46] <dimitern> voidspace, standup?
[10:46] <voidspace> dimitern: oops
[10:46] <voidspace> dimitern: omw
[10:59] <axw> natefinch: hey, is there a bug# already for the sshstorage thing?
[10:59] <axw> if not I'll log one
[11:00] <natefinch> axw: lemme check my IRC history, I don't think so
[11:01] <natefinch> axw: no bug, thanks for making one.
[11:01] <axw> natefinch: thanks
[11:27] <perrito666> ericsnow: ping
[12:33] <voidspace> dimitern: the ipv6 parsing bug in mongo is fixed in 2.7.4
[12:33] <voidspace> dimitern: https://jira.mongodb.org/browse/SERVER-5436
[12:38] <voidspace> dimitern: mgo bug fixed https://github.com/go-mgo/mgo/issues/22
[12:38] <voidspace> dimitern: the only test failure I have with my current replicaset branch is because changing the replicasets can have a delay of several seconds before CurrentConfig returns the new member set
[12:38] <dimitern> voidspace, great news!
[12:39] <voidspace> dimitern: so I might need to go back to an attempt loop, or have WaitFor*Healthy  functions take an expected number of members and have them wait
[12:39] <dimitern> voidspace, so nothing needed for mgo?
[12:39] <voidspace> dimitern: well, only if we move to mongo 2.7...
[12:39] <voidspace> dimitern: I have still filed an issue for mgo
[12:39] <dimitern> voidspace, ah, I see
[12:41] <dimitern> voidspace, using an attempt loop sgtm, we'll see tests passing more quickly anyway
[12:41]  * voidspace lunch
[12:41] <voidspace> dimitern: yep
[12:41] <voidspace> dimitern: I wouldn't like to add an extra parameter to those functions, so I'd have to create a parallel set
[12:41] <voidspace> dimitern: which is just messy
[12:42] <voidspace> dimitern: it's a shame though, attemptLoops make the tests yuckier
[12:42] <dimitern> voidspace, yeah, but at least let them pass more reliably :)
[13:24] <jam> voidspace: waiting for an expected number of members sounds reasonable when we are explicitly setting replicaSet to a specific value
[13:25] <jam> voidspace: it seems like it would just be a helper internally (potentially)
[13:25] <jam> WaitForNHealthy
[13:25] <jam> which Majority passes the right number and All passes a different number, but then you have just one wait
[13:25] <jam> thoughts?
[13:32] <wwitzel3> natefinch: I'm in moonstone
[13:52] <ericsnow> perrito666: back
[13:54] <ericsnow> the CI bot is saying we're blocked on bug #1366802, but it looks like that one is no longer a blocker
[13:54] <mup> Bug #1366802: juju.-gui fails with a config-changed error when used under juju 1.21alpha <ci> <regression> <juju-core:Fix Committed> <juju-gui:Incomplete> <https://launchpad.net/bugs/1366802>
[14:02] <perrito666> brb new bike
[14:06] <mfoord> jam: that's not a bad calls as Add, Remove, Set almost always (maybe always) know the expected number of members
[14:06] <mfoord> jam: if they *always* know then it needn't be exposed any further up
[14:09] <sinzui> natefinch, jam , do you have a minute to review https://github.com/juju/juju/pull/729
[14:10] <sinzui> We are about to reopen CI.
[14:10] <natefinch> sinzui: LGTM'd
[14:11] <sinzui> thank you natefinch
[14:18] <mfoord> jam: hmmm... not quite implemented like that
[14:18] <mfoord> jam: when we do a remove the status will initially report *more* members than we want
[14:19] <mfoord> jam: we want to wait for the new config to be applied (in the case of a Set the number of new and old members may be the same - just *different* members)
[14:19] <mfoord> jam: so wait for config to match *then* wait for healthy
[15:03] <bac> hi jcastro
[15:05] <perrito666> natefinch: wwitzel3 stand up
[15:07] <wwitzel3> perrito666: thanks, sorry
[15:08]  * wwitzel3 shakes fist at test
[15:47] <mfoord> So I've added a wait for the config to be applied and for CurrentMembers to reflect the new addresses of the replicaset
[15:47] <mfoord> I can see from logging that this happens - CurrentMembers returns 3 entries
[15:47] <mfoord> And then *immediately* afterwards the next call to CurrentMembers returns the old config with 5 members
[15:48] <mfoord> and the test fails
[15:48] <mfoord> maybe it depends which mongo instance the CurrentMembers call goes to - and the change has to propagate to them all
[15:49] <jam> mfoord: sounds plausible
[15:49] <mfoord> jam: very annoying
[15:49] <mfoord> jam: I can see in the logging the right number of members, immediately followed by an assert fail due to the wrong number
[15:49] <jam> mfoord: "let your reads and your writes choose their own destiny" (have you seen that talk?)
[15:50] <mfoord> jam: no, I'll search for it
[15:50] <mfoord> jam: I can refresh the session inside the check that the config has been applied
[15:50] <mfoord> jam: but that doesn't guarantee that the next call will succeed
[15:51] <mfoord> jam: so I think we *have* to brute force wait on that one
[15:51] <mfoord> jam: and be aware that config propagation isn't instant - even after all members are reporting healthy
[15:51] <jam> mfoord: http://vimeo.com/95066828
[15:52] <mfoord> jam: thanks
[15:52] <mfoord> but first, exercise and coffee
[16:00] <katco> thank god... nice way to start the day fighting overheating issues
[16:10] <wwitzel3> where can one find an example of bumping the API version and adding backwards compatibility checks?
[16:11] <wwitzel3> this came up as a review comment for a PR of mine and I've never done it
[17:03] <niemeyer> mramm: Where is the meeting taking place? There's nothing in the calendar event
[17:05] <niemeyer> hazmat: ping
[17:06] <hazmat> niedbalski_, pong
[17:06] <hazmat> niemeyer, pong
[17:06] <hazmat> niemeyer, i'm in london this week at a sprint
[17:08] <niemeyer> hazmat: Cool
[17:08] <hazmat> niemeyer, i'm joining we're just wrapping up at the sprint for the day
[17:10] <hazmat> niemeyer, per mramm just going to cancel for this week
[17:11] <niemeyer> hazmat: Yeah, cool
[17:38] <rick_h_> jcw4: lots of good conversation for you? :)
[17:48] <jcw4> rick_h_: sorry missed your comment  -  yeah, I'm very happy by the response
[18:04] <ericsnow> perrito666: FYI, I've landed that latest backups patch and have then next PR up
[18:05] <perrito666> :D
[19:34] <perrito666> does anyone knows where charm proof comes from?
[19:34] <natefinch> marcoceppi: ^^
[19:34] <marcoceppi> perrito666: lp:charm-tools
[19:34] <perrito666> ouch
[19:35] <perrito666> tx marcoceppi
[19:35] <marcoceppi> perrito666: why ouch?
[19:35] <perrito666> marcoceppi: I was about to re-use it for something and It would have been a tiny bit easier if it was part of juju already
[19:36] <marcoceppi> well, that would be cool
[19:38] <perrito666> ok, getting to actually browse code in launchpad is not the happiest ux of my life
[19:38] <natefinch> perrito666: lol
[19:38] <natefinch> perrito666: yuuup
[19:53]  * perrito666 ports to go
[19:53] <natefinch> perrito666: what are you porting to go?
[19:54] <perrito666> natefinch: a subset of what proof does
[19:55] <natefinch> perrito666: interesting
[19:55] <perrito666> I want to be able to figure out if a given path is a valid charm
[19:55] <natefinch> perrito666: we should already have that, right?  We use it for deploy from local
[19:55] <perrito666> natefinch: good point
[19:56] <perrito666> mm I was expecting proof to do more than what I see
[20:40] <katco> can someone have a look at: http://juju-ci.vapour.ws:8080/job/github-merge-juju/607/console
[20:41] <katco> my landing keeps failing for different reasons (3rd attempt). this one looks like it's the package we've created to randomly create errors?
[20:41] <katco> i.e. "wrench"?
[20:42] <katco> ack disregard... didn't see other test failures. it looks like maybe there's some consistency at least
[21:25] <rick_h_> perrito666: let's chat on that as we'll be doing the same thing as part of upcoming charmstore work.
[21:25] <rick_h_> perrito666: some of the proof stuff calls out to services we run for checks against data in the store and the like.
[21:25] <perrito666> rick_h_: I can tell you what I am trying to do and you tell me if I am on the same grounds as you are
[21:25] <rick_h_> perrito666: sounds good
[21:26] <perrito666> rick_h_: I am working on something called charm sync
[21:26] <perrito666> which allows you to edit your charm locally and then upload the edited version to the unit
[21:26] <perrito666> and retry whatever hook you where working on
[21:26] <perrito666> so the idea is
[21:27] <perrito666> I need to check if what I am trying to upload looks like a charm
[21:28] <rick_h_> ok, but looks like a charm is a bit loose as far as proof goes.
[21:28] <rick_h_> are you just looking at sanity checking the metadata and config files for syntax or more?
[21:28] <perrito666> rick_h_: indeed, I just began reading proof to begin somewhere
[21:29] <perrito666> rick_h_: well what drives me is to be able to guess if the cwd is a charm so if the user does not specify a path we can infer it
[21:30] <rick_h_> perrito666: ok, well whever you stick the code for what you do we'll be interested. We'll be looking up kind of run with the 'juju charm' command by updating it to be in Go and work with the charm store changes and a 'juju publish' spec in the coming months.
[21:30] <rick_h_> perrito666: right, so I'd assume that's just a metadata.yaml and a hooks directory tbh.
[21:30]  * rick_h_ actually isn't sure if a hooks dir is required. 
[21:31] <rick_h_> perrito666: ok, well will be on the lookout for what you do to make sure we don't redo stuff already there.
[21:31] <perrito666> rick_h_: Ill make sure to ask before reinventing the whel
[21:40] <menn0> anyone able to do 2 easy reviews?
[21:40] <menn0> https://github.com/juju/juju/pull/724
[21:40] <menn0> https://github.com/juju/juju/pull/726
[21:42] <menn0> waigani: looks like you can merge this now: https://github.com/juju/juju/pull/721
[21:42] <waigani> menn0: done, cheers
[21:43] <waigani> menn0: oh is thumper away today?
[21:43] <waigani> I thought it was tomorrow
[21:44] <menn0> waigani: I'm not completely sure but I thought he might be away for part of the day
[21:44] <waigani> right
[21:44] <menn0> he's definitely out all of tomorrow due to Kiwi PyCon
[21:45] <waigani> he asked me to look at tags vs strings but I don't know what he wants to know about tags vs strings
[21:46] <waigani> maybe dave will know when he comes on
[22:00] <wwitzel3> axw: ping
[22:15] <ericsnow> menn0: I've reviewed both those patches
[22:16] <menn0> ericsnow: thank you
[22:17] <ericsnow> I could use a review on https://github.com/juju/juju/pull/731 (from anyone)
[22:33] <jose> hello, I'm having troubles bootstrapping on EC2, it gets stuck on "Bootstrapping Juju machine agent" and the --debug log doesn't show anything interesting
[22:34] <jose> I have to leave for now but will check in later with some more info if I find it
[22:41] <waigani> thumper: did you see my email about tags and strings?
[22:41] <thumper> no, not yet
[22:41] <waigani> hmm
[22:46] <thumper> https://github.com/juju/juju/pull/733
[22:46] <thumper> sorry, was out a bit this morning, then fixing that ^^^ branch
[22:46] <thumper> about to look at email now
[22:48] <waigani> thumper: sigh, sorry I'll try that again
[22:48] <ericsnow> waigani: thanks for your review BTW
[22:48] <waigani> ericsnow: np
[22:49] <mwhudson> hey so juju in trusty seems unable to parse the current tools streams data
[22:50] <mwhudson> this seems bad?
[22:50] <mwhudson> http://pastebin.ubuntu.com/8313609/
[22:50] <mwhudson> (might only be an arm64 problem)
[22:53] <thumper> hmm... [LOG] 0:00.676 DEBUG juju.mongo TLS handshake failed: local error: unexpected message
[22:53] <thumper> [LOG] 0:00.676 ERROR juju.worker exited "machiner": cannot get machine 0: Closed explicitly
[22:56] <thumper> hmm... intermittent
[23:48] <wwitzel3> so who wants to assist me with figuring out version for a juju run cmd?
[23:49] <davecheney> wwitzel3: sure
[23:50] <wwitzel3> davecheney: so I've been poking around the code, but I really just not sure what to grep for or how are versioning works
[23:50] <wwitzel3> davecheney: axw suggested that I version the API for the new juju run --relation stuff
[23:51] <davecheney> wwitzel3: hmmm, can you clarify what you mean by version ?
[23:51] <davecheney> do you mean the rsult of juju version ?
[23:52] <wwitzel3> nope, sorry, the API version
[23:52] <wwitzel3> davecheney: https://github.com/juju/juju/pull/705/files#diff-b2014e29ee443dbbf3c97c215229c162R156
[23:52] <davecheney> hmm, does this mean a facade ?
[23:53] <davecheney> wallyworld_: r, gc.ErrorMatches, t.error)
[23:53] <davecheney> ... error string = "cannot read info: write /mnt/tmp/gocheck-1598098976185383115/2/home/ubuntu/.juju/environments/.46495aaf107a487881aefccea1b84637518527581/held: no space left on device"
[23:53] <davecheney> ^ build blew up 'cos of that
[23:54] <wallyworld_> davecheney: that happens occasionally for some reason, i need to ask sinzui about it
[23:54] <davecheney> :sad face:
[23:54] <wallyworld_> should work 2nd time
[23:54] <davecheney> righto
[23:58] <davecheney> oh snap
[23:58] <davecheney> i'm on call reviewer