[00:00] <voidspace> this discovery explains a bunch more failures
[00:00] <voidspace> so more progress
[00:00] <wallyworld> great :-)
[00:00] <voidspace> thanks, you've been a great rubber duck :-)
[00:01] <wallyworld> that's me
[00:01] <wallyworld> sinzui: bug 1341589,  there's been a comment made that we did ship godeps source in 1.20 - i made the assertion that we didn't, and i think you didn't think we did either?
[00:01] <_mup_> Bug #1341589: Distribution tarball has licensing problems that prevent redistribution <juju-core:In Progress by wallyworld> <juju-core 1.20:In Progress by wallyworld> <https://launchpad.net/bugs/1341589>
[00:10] <sinzui> wallyworld, oops, we didn't delete all of it
[00:10] <sinzui> wallyworld, I will add that to my list of deletes.
[00:11] <sinzui> wallyworld, actually do we agree that I should delete
[00:11] <sinzui> src/code.google.com/p/go.net/html/charset/testdata/
[00:11] <sinzui> src/github.com/binary132/gojsonschema/json_schema_test_suite
[00:18] <wallyworld> sinzui: nate is following up with the gojsonschema author to get the licensing sorted out for that. i think we can delete the html test data though
[00:19] <wallyworld> sinzui: the gojsonschema repo should be under juju as it was written on canonical time
[00:19] <davecheney> wallyworld: seconded
[00:19] <davecheney> it seems foolish to consume a dependency published in a personal account
[00:19] <wallyworld> nate is dealing with that, i'll follow up with him tonight
[00:20]  * davecheney mentions that he raised this issue 6 weeks ago when this dependency leaked into our codebase
[00:23] <davecheney> rick_h__: can I nag you for more msdn keys
[00:23] <rick_h__> davecheney: wallyworld it was forked from an existing repo though I recall
[00:23] <davecheney> rick_h__: that's just great
[00:23] <rick_h__> davecheney: sure, same software etc?
[00:23] <davecheney> ^ insert heavy sarcasm
[00:23]  * wallyworld has no idea, wasn't involved with the development
[00:23] <davecheney> rick_h__: i'll 'ahem' get the cd somewhere else
[00:23] <davecheney> i'll email you
[00:23] <rick_h__> davecheney: ok souds good
[00:23] <rick_h__> sounds that is
[00:26] <davecheney> rick_h__: thanks, I only have a dodgy xp vm that i've been tending for close to a decade now
[00:26] <davecheney> seriously, the install date of that vm is 2007
[00:28] <rick_h__> davecheney: did you put the other key to use?
[00:28] <rick_h__> davecheney: or do you want that one again?
[00:28] <rick_h__> davecheney: I've got 5 to use so want to make sure I reuse if that's what'll work
[00:28] <davecheney> rick_h__: let me check my irc log
[00:29] <rick_h__> davecheney: k, if you're not using it I can resend that one
[00:29] <rick_h__> davecheney: I just want to check if you need a second NEW one, or if that other one will work
[00:29] <davecheney> rick_h__: i have one starting 39
[00:29] <davecheney> is that win32 or win64
[00:29] <davecheney> because windows is amazing
[00:29] <rick_h__> davecheney: either.
[00:29] <rick_h__> davecheney: so will get you that one and a second one then
[00:30] <davecheney> rick_h__: ok
[00:30] <davecheney> given how short supply they are i'll use this key for a win64 install
[00:30] <davecheney> and keep using my xp 32 bit vm
[00:30] <davecheney> until that becomes unworkable
[00:30] <sinzui> davecheney, MS published free images for web development testing. The work with virtualbox and MS even recommends snapshotting them to prevent them from expiring
[00:30] <rick_h__> davecheney: all good
[00:30] <davecheney> sinzui: linkage ?
[00:31] <davecheney> sinzui: i know this isn't your fault
[00:31] <davecheney> but this is crap
[00:31] <davecheney> if we're developing on windows, we shouldn't be scrapping together resources to get win dev machines
[00:31] <davecheney> this is serious software development, it should be done properly
[00:31] <rick_h__> davecheney: replied
[00:31] <sinzui> davecheney, But I have been using win images in the cloud this year, when I need on, I just start an instance from the snapshot that does the windows tests. it has golang 1.2, python 2.7 and a ssh
[00:32] <davecheney> rick_h__: ta, when you say 'the download' is that the one that I should look for, um, online ?
[00:33] <rick_h__> davecheney: I imagine. I ink it should work on anything of the right version though
[00:33] <rick_h__> davecheney: though you'll know more of windows than me soon
[00:34] <davecheney> yay. life skills
[00:34] <rick_h__> :)
[00:34] <rick_h__> job security, no one else will want to do it!
[00:38] <voidspace> wallyworld: full test suite pass with *some* of the watcher infrastructure copying sessions
[00:38] <wallyworld> voidspace: farking awesome
[00:39] <voidspace> wallyworld: so now to change all the rest
[00:39] <wallyworld> time for you to git push and then go to bed :-)
[00:39] <voidspace> pushed
[00:39] <wallyworld> \o/ tyvm
[00:39] <voidspace> wallyworld: some of them do lovely things like send collections (which have a session reference of course) across a channel
[00:39] <voidspace> so who closes the session then...
[00:39] <voidspace> so those changes will need more thought
[00:39] <wallyworld> lalalalalala
[00:39] <voidspace> probably stick to using the global session and the receiver can copy
[00:39]  * wallyworld covers his ears and pretends not to hear
[00:39] <voidspace> hah
[00:40] <wallyworld> but agree with receiver copying
[00:42] <sinzui> davecheney, Sorry, took forever to find the link, and then remember the blog post about how I got it downloaded
[00:42] <sinzui> http://blog.launchpad.net/general/a-tale-of-two-travesties
[00:43] <sinzui> davecheney, The vhd you want is probably different since windows and ie have changed
[00:44] <davecheney> ok
[00:44] <davecheney> i read that as 'the tale of two transvestites'
[00:44] <davecheney> now I can't unsee it
[00:44] <thumper> wallyworld: I'm in town while the kids are at a movie, I won't be home in time for our meeting start
[00:44] <thumper> movie finishes 10 minutes before our meeting
[00:45] <wallyworld> thumper: np, just ping e whenever
[00:45] <thumper> wallyworld: kk
[00:45] <wwitzel3> thumper: what movie?
[00:45] <thumper> tinkerbell and some pirate...
[00:45] <thumper> hence me not going
[00:45] <wwitzel3> lol, that's why you are in town
[00:45] <thumper> if it was how to train your dragon 2, I probably would have gone
[00:46] <rick_h__> thumper: saw that with the boy, it's ok
[00:46] <perrito666> thumper: that sounds an awful lot like peter pan
[00:46] <perrito666> from an odd point of view
[00:46] <thumper> perrito666: it probably is
[00:46] <wwitzel3> haha
[00:46] <thumper> rick_h__: the dragon one?
[00:47] <rick_h__> yea
[00:47]  * perrito666 would fancy a movie about captain hook and the annoying young boy and his fairy 
[00:48]  * perrito666 saw many kid movie blockbusters on the plane back from the last sprint
[00:48] <perrito666> they had cloudy with a change of burgers 2
[00:49] <perrito666> anyway, Ill go to sleep so I am ready for our "too early to be pleasant" morning meeting, cheers everyone
[00:55] <voidspace> wallyworld: ah, the transaction stuff breaks the test hooks, because they expect a global transaction runner
[00:55] <voidspace> wallyworld: so that needs fixing too
[00:55] <voidspace> shouldn't be too hard
[00:56] <wallyworld> voidspace: yeah, i did something in the blobstore sub repo - we can do something similar here too
[00:56] <wallyworld> go to bed!
[00:56] <voidspace> I could still use a global jujutxn.Runner and have *it* recreate the underlying transaction runner
[00:56] <voidspace> that would actually be nicer
[00:57] <voidspace> the code would look the same... inside state
[00:57] <voidspace> still not very tired :-/
[00:57] <voidspace> haven't got to sleep until around 4am the last two nights
[00:57] <wwitzel3> voidspace: I've been on odd hours as well
[00:57] <voidspace> wwitzel3: morning
[00:58] <voidspace> wwitzel3: we had our scan today - 7 1/2 weeks
[00:58] <wwitzel3> voidspace: morning, congrats, all is well?
[00:58] <voidspace> wwitzel3: I double checked and I wasn't on a sprint that week, which was a relief ;-)
[00:58] <voidspace> yeah, all is well
[00:58] <wwitzel3> wonderful
[00:58] <voidspace> and there's only one - which is a *big* relief
[00:58] <wwitzel3> hah, oh that's right .. sometimes there is more than one in there
[00:59] <voidspace> slightly more likely if you're as old as us
[00:59] <voidspace> wwitzel3: how's you?
[00:59] <wwitzel3> voidspace: really? I didn't know that. I'm well, just messing around with tests still :/
[00:59] <voidspace> apparently so
[01:00] <voidspace> wwitzel3: heh, I've been doing that all day - *just* got the tests passing with some session copying in place
[01:00] <wwitzel3> voidspace: some where something is doing an extra Close on state so when a teardown runs, mgo throws a NPE.
[01:00] <voidspace> ouch
[01:01] <wwitzel3> voidspace: I'm "walking" it now
[01:01] <voidspace> heh
[01:01] <wwitzel3> voidspace: printing and panicing since I could never get gdb working right
[01:01] <voidspace> I was walking JujuConnSuite.SetupTest
[01:01] <voidspace> and that's a beast
[01:02] <voidspace> heh, yeah - panics are very useful for that
[01:02] <voidspace> "stop here"
[01:02] <wwitzel3> yeah, these tests don't use JujuConnSuite, just Base and Mgo suite.
[01:02] <wwitzel3> but it is still a hassle
[01:05] <voidspace> right, I'm going to meditate and hopefully fall asleep
[01:05] <voidspace> see you all tomorrow...
[01:05] <wwitzel3> voidspace: see ya
[01:05] <voidspace> o/
[01:05] <voidspace> thumper: enjoy tinkerbell...
[01:55] <bigjools> sinzui: we get this particular one a lot - it might help a bit if juju had some way to timeout and report that the node has no internet access?
[02:00] <axw> bigjools: what's the problem? machines not coming up because they can't apt-get?
[02:14] <bigjools> axw: I think so
[02:14] <bigjools> it just hangs on bootstrap
[02:16] <axw> hrm, ok. bootstrap *should* time out after 5 minutes by default
[02:19] <menn0> thumper: your change and mine are going to have merge conflicts. sucks to be me :)
[02:25] <axw> wallyworld: there's a new mgo release coming soon, so I think it's best I hold off proposing any changes till I can update
[02:26] <axw> I have some workarounds in the juju code now that will be irrelevant with that
[02:26] <thumper> axw: how soon?
[02:26] <wallyworld> axw: sure, np.
[02:26] <axw> I'll continue on with killing Environ.StateInfo
[02:26] <axw> thumper: don't know sorry
[02:26] <wallyworld> axw: otp, will chat soon
[02:27] <axw> thumper: well, it doesn't say "soon", but upcoming: https://bugs.launchpad.net/mgo/+bug/1340361/comments/1
[02:27] <_mup_> Bug #1340361: RemoveUser of non-existent user has different behaviour with mongo 2.4/2.6 <mgo:Fix Committed> <https://launchpad.net/bugs/1340361>
[02:33] <bigjools> axw: "should" :)
[02:35] <axw> bigjools: I've witnessed the timeout working recently. There was a recent change to add a longer default for MAAS (for !fastpath-installer) -- maybe it's just not reaching that longer timeout yet
[02:35] <axw> can't remember how long's long
[02:35] <bigjools> axw: that would be it
[02:38] <menn0> thumper: I'm done with the review. A few things but nothing major.
[03:10] <wallyworld> axw: michael has made good progress on the io timeout issue; he should be able to push up a fairly complete branch tomorrow and we can pick up from there
[03:12] <axw> wallyworld: cool.
[03:12] <axw> wallyworld: I have moved address propagation to the backlog, pending additional network/relation hook changes
[03:12] <wallyworld> axw: yup, np
[03:18] <thumper> katco: are you still as enthusiastic as your initial blog post?
[03:32] <davecheney> katco: don't answer that, it's a trap
[03:32] <davecheney> thumper: i'm going to head out for lunch
[03:32] <davecheney> do you want to talk to me today about HR stuffs ?
[03:32] <thumper> kk
[03:32] <thumper> davecheney: nah, tomorrow it is
[03:32] <davecheney> thumper: np
[03:39] <thumper> bbl
[03:42] <davecheney> ok, windows 8 install
[03:42] <davecheney> complete
[03:43] <davecheney> brb, just going to drink some cynaide
[03:43] <wwitzel3> It's good over ice
[03:43] <davecheney> mmm, laudinum
[04:32] <jam> wwitzel3: you got jetlag going from southeast US to northeast US ?
[04:50] <thumper> wallyworld: I think I remember why that provisioner code was there
[04:50] <thumper> wallyworld: got a minute?
[04:50] <wallyworld> sure
[04:50] <thumper> https://plus.google.com/hangouts/_/g6p7d3ldngpmaqhkp5pqyyhidia?authuser=1&hl=en
[05:26] <menn0> thumper: any chance you can look at https://github.com/juju/juju/pull/322
[05:26] <thumper> menn0: yep, just doing some hr stuff first
[05:26] <menn0> thumper: ok
[05:47] <thumper> menn0: done
[05:47] <thumper> dinner time
[05:47] <thumper> back for meeting in 4 hours
[05:48] <thumper-afk> bugger
[06:23] <rogpeppe> mornin' all
[07:11] <menn0> thumper: thanks for the review. merging now.
[08:09] <mattyw> davechen1y, ping ping?
[08:11] <mattyw> davechen1y, cancel that
[08:25] <voidspace> morning all
[08:25] <jam> morning voidspace
[08:25] <voidspace> o/
[08:28] <Egoist> Hi
[08:28] <Egoist> is -relation-departed hook is executed after remove unit from service?
[09:14] <dimitern> Egoist, quoting juju-core/doc/charms-in-action.txt: The "relation-departed" hook for a given unit always runs once when a related unit is no longer related. After the "relation-departed" hook has run, no further notifications will be received from that unit; however, its settings will remain accessible via relation-get for the complete lifetime of the relation.
[09:24] <dimitern> jam, ping
[09:24] <jam> dimitern: /wave
[09:25] <dimitern> jam, should we have a quick hand-off chat re networking?
[09:25] <jam> certainly
[09:25] <jam> give me a sec to grab headphones
[09:25] <dimitern> sure
[09:25] <TheMue> dimitern: jam: any interesting regarding ipv6 (especially for lxc) here?
[09:26] <dimitern> jam, i'm in the standup g+
[09:27]  * TheMue simply will join too
[09:27] <dimitern> TheMue, come as well yes
[09:27] <perrito666> morning everyone
[09:27] <dimitern> morning perrito666
[09:27] <TheMue> perrito666: o/
[09:28] <voidspace> jam: with this code all the tests pass (there's "some" session copying going on in the watchers)
[09:28] <voidspace> https://github.com/voidspace/juju/compare/master...copy-sessions
[09:28] <voidspace> jam: that removes the password hashing from the dummy provider and also from JujuConnSuite
[09:29] <jam> TheMue: dimitern: want to join me in https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
[09:29] <TheMue> jam: already in
[09:34] <jam> axw: what was the final results of address changes for charms?
[09:35] <jam> voidspace: sounds good, I wanted to check with the list that it was time we could do it, but it sounds like we are ready
[09:35] <voidspace> cool
[09:37] <axw> jam: not much for now. for the short term, I've updated the uniter so that config-changed is triggered on machine/unit address change. in the longer term, (I think?) there will be a relation equivalent of config-changed that will be triggered when relation addresses change
[09:37] <axw> so, no automatic changes for now
[09:37] <axw> I've moved the card to the backlog
[10:06] <jam> mgz: ping for team standup?
[10:27] <wwitzel3_> jam: hah, I guess I did. (re: jet lag)
[10:29] <voidspace> what else is using juju/txn now that it has been broken out into a separate package?
[10:30] <voidspace> 'coz I want to change the transaction runner in a backwards incompatible way
[10:31] <natefinch> voidspace, wwitzel3: all team meeting?
[10:31] <wwitzel3> natefinch: yep, sure
[10:32] <voidspace> natefinch: I can join
[10:32] <voidspace> for the sake of nostalgia
[10:33] <voidspace> oh!
[10:33] <voidspace> all team meeting
[10:33] <voidspace> cool
[10:52] <mgz> doh, should have looked at calendar
[10:54] <Guest63023> voidspace: blobstore
[10:55] <voidspace> Guest63023: ok, thanks
[10:55] <voidspace> wallyworld: ah, I wondered who you were :-)
[10:55] <voidspace> wallyworld: so I want to make the underlying transaction runner do the session copying
[10:55] <wallyworld> stupd freenode
[10:56] <voidspace> wallyworld: as that's the correct thing to do
[10:56] <voidspace> wallyworld: but it changes the signature of NewRunner
[10:56] <wallyworld> voidspace: go for it, tht would be awesome'
[10:56] <wallyworld> i'll fix blobstore
[10:56] <voidspace> wallyworld: and only the replicaset tests fail when I do that
[10:56] <wallyworld> they fail a lot anyway :-)
[10:56] <voidspace> wallyworld: although obviously the txn tests themselves won't run
[10:57] <voidspace> hah
[10:57] <voidspace> they fail deterministically now
[10:57] <voidspace> so I guess you could call that progress...
[10:57] <wallyworld> yup :-D
[10:57] <wallyworld> we should do what's the best approach and fix tests accordingly
[10:57] <voidspace> only one fails, and it looks like it's the ipv6 one
[10:58] <wallyworld> hmmm, that may be different root cause?
[10:58] <voidspace> well, it was passing and now it's failing...
[10:58] <voidspace> but the specific error is that ""exception: need most members up to reconfigure, not ok"
[10:58] <wallyworld> there's one ip6 one that has been flakey
[10:58] <voidspace> which maybe indicates a timing issue
[10:58] <wallyworld> yep
[10:58] <voidspace> I don't think it's this one that is the normally flaky one
[10:59] <wallyworld> hmmm, strange that it's just the 1 test
[10:59] <voidspace> this one just starts a replicaset with members location specified using ipv6 format (so the replicaset members talk to each other over ipv6)
[10:59] <voidspace> yeah, I'm digging into it
[10:59] <wallyworld> can't see how session clone relates to that, unless sockets somehow break on ip6
[11:00] <voidspace> it may just be that the extra connections need some extra time
[11:00] <wallyworld> that would be more plausible
[11:00] <wallyworld> try increasing the sleep just for shits and giggles to see what happens
[11:01] <voidspace> yep
[11:01] <voidspace> but coffee first
[11:11] <mgz> interestingly the bot has been pretty solid for the last few days
[11:11] <mgz> all the red seems to be real issues
[11:24] <dimitern> mgz, really? I had 2 reds yesterday - one landed successfully, the other was genuine
[11:26] <mgz> dimitern: ah, the only one of yours I saw looked real
[11:27] <dimitern> mgz, there was a test failure previously on the same PR
[11:28] <dimitern> mgz, the funny thing though is how jenkins decides to mark a build red very early.. seems fishy
[11:29] <mgz> oh, yeah, something jenkinsie went wrong on 43, which wasn't test related
[11:29] <mgz> I forgot that I'd requeued that
[11:31] <axw> wallyworld: I'm not going to make the standup, team meeting ate into dinner
[11:32] <mgz> they ate your dinner?!
[11:32] <wallyworld> axw: no problem at all, talk tomorrow
[11:32] <axw> wallyworld: I've got my StateInfo branch all working, need to tidy up and split it
[11:32] <wallyworld> great :-)
[11:32] <axw> and now there seem to be more action test races
[11:33] <wallyworld> :-(
[11:33]  * axw goes for dinner
[11:33] <wallyworld> axw: i'd like to continue to remove ome more old cruft too
[11:46] <wwitzel3> why would a test be trying to actual create a machine with the 'someprovider' from the FakeConfig when calling AddMachine?
[11:47] <wwitzel3> the testing is erroring with  value *errors.errorString = &errors.errorString{s:"no registered provider for \"someprovider\""} ("no registered provider for \"someprovider\"")
[11:58] <wallyworld> katco: mgz: i'll be a bit late for standup, in another meeting
[11:59] <mgz> wallyworld: poke when ready
[12:00] <axw> poke me too, I finished dinner and am around atm
[12:03] <katco> good morning all
[12:04] <voidspace> katco: o/
[12:04] <katco> voidspace: hallo
[12:05] <voidspace> wallyworld: just FYI, it was a timing issue - around destroying instances
[12:05] <voidspace> wallyworld: we need to give the replicaset time to adjust
[12:05] <wallyworld> voidspace: yeah, thought so :-)
[12:05] <voidspace> wallyworld: not sure why it wasn't biting us before
[12:05] <wwitzel3> katco: morning
[12:05] <voidspace> wallyworld: we have some "strategy" code around the other operations to deal with it
[12:05] <wallyworld> that's the natue of it
[12:05] <katco> wwitzel3: howdy
[12:05] <voidspace> wwitzel3: but weren't using it around Remove
[12:05] <wallyworld> sigh
[12:05] <voidspace> oops, sorry wwitzel3
[12:06] <voidspace> wallyworld: well, I'm happy it was an easy fix
[12:06] <wallyworld> voidspace: yes :-)
[12:06] <voidspace> wallyworld: I have a doctors appointment soon - but should have a txn branch to propose later today
[12:06] <wallyworld> katco: morning, i'm running late, in another meeting
[12:06] <wallyworld> voidspace: you're awesome
[12:07] <katco> wallyworld: no worries, just yell when you're ready
[12:07] <voidspace> wallyworld: haha, wait until you see how much I leave you to do before you say that
[12:07] <voidspace> wallyworld: but thanks
[12:07] <wwitzel3> lol
[12:07]  * wallyworld is nervous :-)
[12:08] <katco> voidspace: you rewrote juju in python didn't you
[12:08] <mgz> rerewrote
[12:08] <voidspace> katco: we actually came up with a way to do that
[12:08] <katco> rofl
[12:08] <voidspace> a go to python source translator would be relatively easy
[12:08] <katco> -.-
[12:08] <wwitzel3> hah
[12:09] <voidspace> so we do that, run it once, then switch to Python dev
[12:10] <voidspace> mgz said he would work on it over the weekend
[12:10] <mgz> >_<
[12:10] <voidspace> :-)
[12:10] <katco> haha
[12:13] <katco> axw: replied to your latest review comment (thank you). so i'm OK to add a file-lock to the bootstrap command?
[12:14] <wallyworld> mgz: katco: ready :-)
[12:14] <axw> katco: thanks, will read them in a bit. i'm not sure - is it actually possible to get into the race condition with the same $JUJU_HOME? the .jenv file is meant to be a sort of lock
[12:15] <katco> axw: maybe we can discuss a little at the end of the standup
[12:26] <cmars> jam1, sure
[12:26] <cmars> joining
[12:26] <cmars> oh
[12:36] <vladk> dimitern: ping
[12:39] <perrito666> does anyone know how to get a user/password to connect to a github.com/juju/testing . MgoInstance?
[12:48] <natefinch> perrito666: sorry, I'm not sure.  If you figure it out, can you make a quick PR to put that info in the comments of MgoInstance?
[12:50] <perrito666> natefinch: I certainly will once I do
[12:53] <natefinch> mgz, dimitern, rogpeppe, jam:  any of you guys able to point perrito666 to how he can get the user/password for a testing.MgoInstance?
[12:53] <jam> natefinch: user admin
[12:53] <jam> password dummy-secret IIRC, or testing.DefaultMongoPassword ?
[12:58] <perrito666> jam: testing.DefaultMongoPassword does not work I get auth fails, Ill keep looking , I eventually will figure out or throw the computer over the window
[12:58] <jam> perrito666: where in the code are you trying to do it?
[12:59] <jam> perrito666: environs/dummy/environs.go Bootstrap sets the password to Config().AdminSecret()
[12:59] <jam> (or the hash of it before first connect)
[12:59] <jam> (line 654)
[13:00] <perrito666> jam: I am writing tests for the new restore, most, if not all uses in tests use MustDial ¯\_(ツ)_/¯
[13:00] <jam> perrito666: so for restore, are we bootstrapping with the dummy environ?
[13:00] <jam> if we haven't ever connected to it before then the password should be Hash(password)
[13:01] <jam> but in real "restore" wouldn't the jujud have come up at least 1 time?
[13:01] <jam> maybe in testing it hasn't
[13:01] <jam> perrito666: so I have to ask a bit where this is getting set up, as it probably makes a difference
[13:02] <jam> until you bootstrap, I don't tihnk we have any users in mong
[13:02] <jam> mongo
[13:05] <jam> perrito666: fwiw voidspace has been working in this place a bunch right now, he might have answers if I'm out
[13:05] <perrito666> jam: mm, I see I have not yet connected to it at that point, I am writing tests for the function that re-sets replset
[13:05] <bodie_> morning #juju-dev :)
[13:05] <perrito666> jam: tx for the info :)
[13:05] <perrito666> bodie_: hi
[13:05] <jam> morning bodie_
[13:11] <TheMue> bodie_: heya
[13:13] <abentley> sinzui: chat?
[13:13] <sinzui> yes
[13:13] <abentley> https://plus.google.com/hangouts/_/calendar/Y3VydGlzQGNhbm9uaWNhbC5jb20.5o5o70vgo1v23fjnopr1famgrg?authuser=1
[13:23] <bodie_> TheMue, did you have anything more to add on PR 311?
[13:24] <bodie_> I was talking about a change to the whole thing with fwereade -- I have some content I've been working on but refactoring the tests ended up being a big chunk
[13:27] <TheMue> bodie_: will take a look
[13:28]  * TheMue ’s irc client forgot to notify me in case of a mention :(
[13:35] <natefinch> bodie_: can you put that license file in gojsonschema ASAP?  It's blocking our release
[13:36] <natefinch> bodie_: I presume the right thing to do is just pull down the one added to the upstream repo
[13:39] <bodie_> natefinch, sure, give me 5 minutes to wrap up here.  mgz gave me the impression it wasn't a front of the line concern, sorry to keep you waiting
[13:39] <natefinch> bodie_: it's ok, I didn't really follow up yesterday.
[13:39] <natefinch> FWIW, I blame mgz too ;)
[13:41] <perrito666> voidspace: ping?
[13:41] <voidspace> perrito666: I have to go to the doctors - like *right* now
[13:41] <mgz> bodie_: finishing your branch was more important, which you did :)
[13:41]  * bodie_ throws a tomato at mgz
[13:42] <perrito666> voidspace: no hurry
[13:42] <voidspace> perrito666: I shouldn't be long though and we can talk when I get back
[13:42] <perrito666> cu later or tomorrow
[13:42] <voidspace> perrito666: ok
[13:42] <bodie_> mgz, if it LGTY, LMK ;)
[13:43] <mgz> TSGTM
[13:43]  * natefinch just figured out bodie_'s github account name
[13:44] <bodie_> hehehe
[13:44] <bodie_> now I feel a little silly... that name is a throwback to my teens
[13:44] <natefinch> haha
[13:45] <bodie_> mgz, natefinch, did you want to have a brief chat about whether we should be using my repo or try to get a proper update merged into xeipuuv's?
[13:45] <natefinch> bodie_: neither.  we should fork yours into github/juju
[13:45] <bodie_> that's what seemed reasonable to me as well
[13:46] <natefinch> bodie_: I'm not confident that xeipuuv will keep it up to date, and since it's written on canonical time, it should be in a canonical repo
[13:46] <bodie_> that was my primary reason for keeping my work in my fork, he seemed unresponsive on some queries
[13:46] <natefinch> also, we don't want to be blocked on some external person accepting our pull requests for our code to work
[13:46] <bodie_> right
[13:46] <bodie_> can I simply create a repo in juju?
[13:47] <mgz> nate can
[13:47] <natefinch> you can't, but I can.  I think what we'll do is have you put the license in your repo, and then I'll just fork your repo into juju
[13:47] <bodie_> cool
[13:47] <mgz> I do want the gap between upstream and us to be as small as possible, and them to be aware of our changes
[13:48] <perrito666> natefinch: bodie_ you made me look up
[13:48] <natefinch> mgz: that's pretty fair.  Maybe fork upstream and merge in bodie_'s changes?
[13:48] <natefinch> perrito666: haha
[13:48]  * perrito666 notices he has been wearing his headphones without music for 2 hs
[13:49] <natefinch> perrito666: haha, I do that all the time. :)
[13:49] <bodie_> hate it when that happens... I don't want sweaty ears unless I'm getting something out of it! :P
[13:49] <natefinch> https://github.com/juju/gojsonschema
[13:49] <perrito666> bodie_: its winter, my ears feel pretty good about the heat
[13:50] <bodie_> natefinch, I'll poke a change into core quickly to use that and whatnot
[13:50] <natefinch> bodie_: ok.  I need to merge in your stuff first.  hopefully it'll just work :/
[13:51] <bodie_> I'll give it a shot too
[13:51] <bodie_> erm, it looks like it's still using the other two bad deps
[13:51] <natefinch> bodie_: in theory, all the fixes you made will just work
[13:52] <bodie_> sigu-399/gojson* was a big pain point that I had to rework
[13:52] <bodie_> *pokes natefinch*
[13:57] <natefinch> merge conflict?  damn
[13:58] <bodie_> natefinch, there's also a couple of bad deps in that
[13:58] <bodie_> not sure if you saw
[13:58] <bodie_> I pulled out all three libs
[13:58] <bodie_> gojsonschema, gojsonreference, and gojsonpointer
[13:58] <natefinch> bodie_: right, but if I pull in your changes, it should put the juju repo in the same state as your repo
[13:58] <bodie_> should've thought to mention that -_-
[13:59] <natefinch> "should"
[13:59] <bodie_> well, my gojsonschema repo, yes
[13:59] <bodie_> but gojsonschema has two more or less shoddy external dependencies in sigu-399's account
[13:59] <bodie_> which I fixed
[13:59] <natefinch> yeah, all I'm doing is forking your upstream and then merging in your changes
[14:00] <bodie_> I'm not sure which one of us is failing to understand the other, haha
[14:00] <natefinch> bodie_: oh, I see, there's more than the one repo, I get it.  gojsonreference
[14:01] <bodie_> and gojsonpointer
[14:01] <natefinch> gah, those have no licenses either
[14:01] <bodie_> it's prepended to the file, which is acceptable under apache 2
[14:02] <bodie_> I wasn't totally sure whether that was an issue
[14:02] <natefinch> oh, cool, yeah, that's fine
[14:02] <perrito666> natefinch: stdup?
[14:03] <natefinch> yep
[14:25] <natefinch> perrito666: sorry, no I haven't done the set state server address thing
[14:27] <katco> mgz: so i'm wondering if this variable name is appropriate, "existing". it's only true if there is an error and the error is that the environment path _doesn't_ exist
[14:32] <bodie_> heh
[14:32] <katco> mgz: it's causing some mental gymnastics, and actually might be the source of _a_ bug; e.g.: we cleanup only if an environment was already found, not created
[14:33] <bodie_> they may be in a standup, btw
[14:33] <bodie_> not sure how they do things
[14:33] <katco> mgz?
[14:33] <katco> he's on my team, not sure if he goes to other stand-ups
[14:34] <perrito666> katco: he uses irssi, he might not get notified of your pings
[14:34] <mgz> sec, just wombled off
[14:34] <katco> perrito666: ah ok :) i used to use irssi; migrated to erc recently
[14:35] <katco> mgz: wombled... that is a new phrase for me
[14:35] <mgz> 'existing' should be refering to if there was a .jenv file *before* we called Prepare
[14:35] <mgz> which sort of makes sense
[14:36] <mgz> there are just too many negatives in there to make that clear :)
[14:36] <katco> mgz: haha, yeah... even as i'm trying to clarify i have to reparse this in my head
[14:36] <mgz> ReadInfo -> !IsNotFound -> existing = true
[14:36] <bodie_> oy
[14:36] <bodie_> isn't not found?
[14:36] <mgz> !existing -> destroy
[14:37] <bodie_> wouldn't that mean IsNotFound -> destroy?
[14:37] <mgz> right, any err other than not found means you fall through and existing remains = false
[14:38] <mgz> (or err == nil in the common but not-explict case)
[14:38] <mgz> the code is just generally confusing
[14:40] <katco> mgz: so, true iff either there is no error OR there exists an error but it's not that we couldn't find the env
[14:41] <mgz> katco: the reverse, false iff...
[14:41] <mgz> wait, now I'm backwards?
[14:41] <katco> mgz: haha this code is a mental trap
[14:42] <mattyw> sorry for missing the core team meeting today folks - completely missed the reminder
[14:42] <mgz> yours was right
[14:42] <katco> mgz: i think i'm correct which is perhaps why there's a bug
[14:48] <katco> mgz: right, b/c currently if there _is_ an error, but it's something other than "couldn't find env", it will still mark "existing = true"
[14:49] <mgz> right, which is wrong
[14:49] <katco> mgz: i think this should occur: existing = (err == nil)
[14:49] <katco> i think that's true for all cases
[14:49] <mgz> yeah, I think so
[14:50] <katco> mgz: i think i have the fix; but i think you're going to be the only one who can review it haha
[14:51] <katco> mgz: take a peek at this and let me know what you think: https://pastebin.canonical.com/113716/
[14:52] <mgz> yah, the three states seem correct there
[14:53] <katco> mgz: awesome, i'll go with this. the test i have seems to agree
[14:53] <mgz> you can probably just do if err == nil { envExists = true } else if IsNotFound(err) { ...warning.. } else { return err }
[14:54] <katco> mgz: i am not a huge fan of relying on default values, but i'm not opposed if you feel strongly
[14:55] <katco> mgz: or wait, did i misread that...
[14:55] <mgz> katco: I mostly just like simple diffs, I agree reassigning envExists isn't super
[14:55] <katco> mgz: +1 on simple diffs
[14:56] <mgz> but really it's an either-or for the first two blocks
[14:56] <mgz> as unexpected errors we should just propogate rather than go on and Prepare at all
[14:58] <katco> mgz: i like your way better... reads cleaner
[14:58] <katco> mgz: other than the default value ;)
[15:03] <natefinch> katco: can you fix the comment on environFromName so it explains what the function is for that it returns?
[15:04] <katco> natefinch: sure... would naming the return param work?
[15:04] <natefinch> katco: yeah, I was going to suggest that too... can you do both, though?  Cleanup is a good name, but it still doesn't describe when you should call it and stuff.  Pretend you're brand new and have no idea what most of this code does :)
[15:05] <mgz> that's all of us...
[15:05] <katco> natefinch: well that's not hard to pretend ;) but yeah, i'll do both. tyvm for the suggestion
[15:05] <natefinch> right
[15:06] <natefinch> that's actually something I'd like us to work on... put as much helpful information in comments as possible for the next developer, instead of assuming the next person has a perfect comprehension of the mechanics of the entire system.
[15:06] <katco> do we prefer line breaks for each arg, or several on a line but break before c80?
[15:07] <natefinch> katco: up to the individual developer as long as gofmt likes it.  Personally, I prefer one arg per line like a struct declaration, instead of randomly breaking somewhere in the middle of the args
[15:07] <katco> natefinch: +1
[15:08] <katco> natefinch: although the indentation isn't how i would do it:
[15:08] <katco> func environFromName(ctx *cmd.Context,
[15:08] <katco> 	envName string,
[15:08] <katco> 	resultErr *error,
[15:08] <katco> 	action string) (environs.Environ, func(), error) {
[15:08] <katco> natefinch: i'd like for the args to be under the first, and bringing the 1st down a line reads strangely to me
[15:09] <natefinch> katco: this is my own personal favorite way:
[15:09] <natefinch> func destroyPreparedEnviron(
[15:09] <natefinch> 	bar *cmd.Context,
[15:09] <natefinch> 	baz environs.Environ,
[15:09] <natefinch> ) (foo, error) {
[15:10] <natefinch> reads a lot like a struct definition, which my eyes parse easily
[15:10] <katco> natefinch: i like that
[15:10] <natefinch> but again, the Juju rule is, if gofmt likes it, it's ok
[15:10] <katco> natefinch: consider it adopted! :)
[15:10] <natefinch> cool
[15:10] <katco> that is very easy to parse for me
[15:30] <alexisb> natefinch, team: anyone have time to take a look at this bug today:
[15:30] <alexisb>  https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1078213
[15:30] <_mup_> Bug #1078213: logs are not logrotated <amd64> <apport-bug> <canonical-is> <canonistack> <logging> <precise> <juju-core:Triaged> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1078213>
[15:31] <alexisb> it is starting to affect the field
[15:33] <natefinch> alexisb: I can look at it.  I've wotked on it before
[15:34] <natefinch> worked
[15:35] <katco> mgz: i've found another curiosity... cleanup gets passed in a pointer to an error, and if the error is nil, returns. as far as i can tell, that error will never be anything but nil...
[15:36] <natefinch> alexisb: can you add wayne to canonical-juju?  evidently he's not on it
[15:36] <alexisb> o, yeah let me see how to do that
[15:37] <katco> natefinch: alexisb: i'm not sure i'm on that either
[15:37] <alexisb> katco, ack
[15:37] <mgz> katco: you mean the resultErr to destroyPreparedEnviron?
[15:37] <katco> alexisb: at least a quick search shows no messages
[15:37] <katco> mgz: yeah
[15:38] <mgz> that's a funky defer hack
[15:38] <katco> mgz: am i just reading that wrong? it never gets set?
[15:38] <mgz> cleanup is defered till the end of Run, which has the named return resultErr
[15:39] <mgz> which was passed *as a reference* to environFromName and on into cleanup
[15:39] <katco> mgz: right, but we never do anything with it as far as i can tell
[15:39] <katco> mgz: in any of the stack frames
[15:39] <mgz> so, when cleanup runs, *after* the return from Run, it's populated with the return err from that runction
[15:39] <katco> mgz: ooooh i see
[15:40] <katco> mgz: jees... that is not intuitive at all
[15:40] <mgz> what we do with it is *err == nil
[15:41] <katco> mgz: a defer func() { if resultErr != nil { cleanup() } }() would be much clearer
[15:41] <natefinch> ericsnow: 1:1 in moonstine?
[15:41] <mgz> so, cleanup does not destroy if Run returned successfully
[15:41] <ericsnow> natefinch: coming
[15:41] <mgz> yes, having two levels of guards on destroy is just confusing
[15:42] <katco> mgz: so the ever-present question: do i make that change?
[15:43] <mgz> you could pull it up into cleanup pretty trivally if it's not used otherwise, which it seems not to be
[15:43] <katco> mgz: i agree
[15:44] <katco> mgz: and i apologize; regarding this morning's discussion; if the environ already existed, we just want to remove the jenv file, not destroy the entire thing, correct?
[15:50] <katco> mgz: hm it looks like that pattern (err ref in cleanup) is also used in synctools
[15:52] <dimitern> anyone willing to review a small fix for bug 1343219 ? https://github.com/juju/juju/pull/327
[15:52] <_mup_> Bug #1343219: networker restarts every 3 seconds with the local provider (missing /etc/network/interfaces) <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1343219>
[15:54] <TheMue> voidspace: to allow a review, could you add a bit more information to your txn PR?
[15:54] <voidspace> TheMue: which bit don't you understand?
[15:54] <voidspace> ;-)
[15:54] <voidspace> TheMue: ok
[15:55] <TheMue> voidspace: it’s more the general comment for the whole PR, about the intention
[15:55] <voidspace> TheMue: yep, no problem
[15:56] <TheMue> voidspace: great, thx
[15:56] <dimitern> TheMue, voidspace ^^ ? :)
[15:56] <TheMue> voidspace: btw, I’m taking some notes about IPv6 in LXC containers
[15:57] <TheMue> dimitern: will take a look
[15:57] <voidspace> dimitern: eh?
[15:57] <voidspace> ah
[15:57] <voidspace> TheMue: great
[15:57] <dimitern> :)
[15:58] <dimitern> TheMue, ops, sorry - I had to fix a test slighly, but the rest is fine
[15:59] <voidspace> Sooo... in order to use collections safely we should copy them before performing any actions on them
[15:59] <voidspace> in order to use a new session
[15:59] <voidspace> unfortunately State is a big bundle of collections
[15:59] <voidspace> I'm considering replacing the collections with a function to return a collection instead
[16:00] <voidspace> so it's impossible to access them without creating a new copy
[16:00] <voidspace> however, wherever they're copied a closer function is also returned - so session.Close can be called appropriately
[16:00] <voidspace> that's going to create some uglyish code
[16:01] <voidspace> it will make it more likely that I catch all the places using collections though
[16:01] <voidspace> I think it needs an email to juju-dev
[16:01] <wwitzel3> hey dimitern , any idea why one of my tests in state (calling AddMachine) would be returning an error that there is no registered provider for "someprovider" which is the details from FakeConfig.
[16:01] <natefinch> voidspace: definitely
[16:02] <dimitern> wwitzel3, I've never seen that :/
[16:02] <voidspace> natefinch: my branch with some session copying for the watchers - and session copying for the transaction runner - passes all the tests
[16:02] <voidspace> wwitzel3: that sounds to me like some mocking isn't taking effect
[16:02] <natefinch> voidspace: nice
[16:02] <voidspace> wwitzel3:  something that's supposed to be catching calls isn't and they're propagating too far
[16:02] <TheMue> dimitern: ping me when you fixed the test, the rest indeed looks good
[16:02] <dimitern> wwitzel3, i seem to recall some piece of code getting a fakeconfig and changing the type to "someprovider" though
[16:03] <natefinch> voidspace: that'll help with our scaling up as well.
[16:03] <wwitzel3> voidspace, dimitern: yeah the fake environ is setup and it is even using the dummy provider
[16:03] <wwitzel3> voidspace, dimitern: I have one test that it works on and one test is fails on, so right now i'm just talking the code to see where the passing one mocks and the failing one doesn't
[16:05] <dimitern> wwitzel3, so which test passes and which fails?
[16:05] <bodie_> mgz, hangout or are we good?  I don't have any real questions yet, I'm just starting to dig into the jujuc stuff
[16:06] <dimitern> TheMue, PR updated
[16:07] <TheMue> dimitern: ok
[16:07] <wwitzel3> dimitern: the failing ones for me are in the megawatcher tests and many of them pass in the other suites in state.
[16:07] <wwitzel3> dimitern: I am sure it has to do with me not mocking something properly with the new refactors I've made, I was just hoping for a pointer in the right direction for where that gets mocked.
[16:09] <wwitzel3> I feel like it should just be calling the AddMachine from dummy provider
[16:09] <wwitzel3> and that should be that
[16:09] <dimitern> wwitzel3, why you need an environment in state tests?
[16:10] <TheMue> dimitern: reviews
[16:10] <dimitern> wwitzel3, I mean - state tests usually don't mess with provider types, etc. just set and get the envconfig
[16:10] <TheMue> dimitern: eh, reviewed
[16:10] <dimitern> TheMue, ta!
[16:10] <TheMue> dimitern: quick solving of the issue
[16:10] <wwitzel3> dimitern: because this megawatcher_internal_test calls AddMachine a lot.
[16:11] <wwitzel3> dimitern: I'm not messing with them in the tests, I've messed with things in general and I'm trying to fix the tests :)
[16:11] <dimitern> TheMue, it's quick-n-dirty fix for now - we'll probably have to handle missing /etc/network/interfaces better in the future
[16:11] <dimitern> wwitzel3, ah :)
[16:12] <dimitern> wwitzel3, sorry I couldn't help you more
[16:12] <wwitzel3> dimitern: no worries, appreciate the time, I'll get it figured out
[16:12] <wwitzel3> it is most likely something simple and dumb
[16:12] <wwitzel3> and completely my fault :)
[16:12] <TheMue> dimitern: yep, we need to know if it is needed or, like in the mentioned case, not
[16:13] <dimitern> I know the feeling - esp. when I mess around with stuff in state
[16:13] <dimitern> TheMue, or create it ourselves even
[16:13] <dimitern> ok guys
[16:13]  * dimitern is off - see you in 2 weeks ;)
[16:29] <natefinch> bodie_: one of the jsonschema tests is panicking?
[16:30] <natefinch> bodie_: http://pastebin.ubuntu.com/7809812/
[16:33] <bodie_> natefinch -- hrm
[16:33] <hackedbellini> thumper: we just tried the workaround you mentioned yesterday, but it didn't work :(
[16:33] <hackedbellini> natefinch: to update you, yesterday after you left, thumper said our problem here is probably because it was missing "ha" (I don't know what that means =P), and it was caused because we upgraded from 1.19 to 1.20 and not from 1.18 to 1.20 (that second migration would trigger that "ha" to be properly setup)
[16:33] <hackedbellini> as a workaround, he said we could try changing the "upgradedToVersion" on machine-0's agent.conf to read "1.18.4" instead of "1.19.3" so when the agent started, it would maybe fix it
[16:34] <bodie_> natefinch, is this using my deps?
[16:34] <bodie_> mine is passing
[16:45] <katco> apparently errors.IsNotFound(nil) returns false
[16:47] <natefinch> bodie_: ahh yeah, I was missing your changes to gojsonreference
[16:48] <natefinch> katco: yeah, most "isFoo" should return false on nil
[16:48] <natefinch> especially when checking interfaces
[16:48] <katco> natefinch: generally agreed, but it makes "if environInfo, err := store.ReadInfo(envName); nil == err || !errors.IsNotFound(err) {...}" all the more confusing
[16:49] <natefinch> katco: double negatives are always a problem
[16:50] <natefinch> katco: and yeah, that ode is not very good.  I would split out the if statement from the rest... I generally only do the inline if statement if it's super simple
[16:50] <natefinch> line returns are free, developer confusion is expensive
[16:50] <katco> natefinch: yeah that's what we've decided to do; but i missed a case
[16:51] <katco> natefinch: i don't know why, but this particular block of code is really good at scrambling people's brains
[16:51] <natefinch> katco: show me?
[16:51] <natefinch> file/line no
[16:51] <katco> natefinch: the code? it was what we were discussing earlier
[16:52] <katco> natefinch: common.go, environFromName
[16:52] <katco> natefinch: it's going to look different by the time i submit a PR
[16:53] <natefinch> katco: that sounds like a good thing :)
[16:53] <katco> natefinch: absolutely... axw, mgz, and i were thoroughly confused
[16:55] <katco> natefinch: but i think one of them will have to be the reviewer, otherwise it looks like much too large of a PR
[16:57] <katco> speaking of which... i've never done this. so i've made changes since my last PR, and i want to resubmit. does github handle that for me, or how do i submit a fresh PR?
[16:58] <perrito666> katco: if your pr has not beenmerged
[16:58] <perrito666> just push
[16:58] <perrito666> that updates the pr
[16:58] <katco> perrito666: ah ok. ty
[16:58] <natefinch> depends... pushing will put another commit on the PR, or you can rebase to update the commit already in the PR.
[16:59] <katco> natefinch: so if i rebase from trunk, it will update the PR but erase prior history (comments, etc.)?
[16:59] <natefinch> right
[17:00] <natefinch> so, not rebasing means you keep the comments
[17:00] <natefinch> ...and this is why we want to move to reviewboard, so it's simpler and easier
[17:00] <natefinch> I think
[17:00]  * natefinch has not actually used reviewboard
[17:01] <katco> cool
[17:02] <natefinch> bodie_: ok, so all the jsonschema stuff is now under github.com/juju
[17:02] <bodie_> right on
[17:03] <bodie_> natefinch, shall I open a PR to correct the imports and godeps?
[17:03] <natefinch> bodie_: yes please
[17:04] <katco> natefinch: btw, in environs/configstore/disk.go, my initial impression is all of those mutexes should be removed, and the variables be converted to a non-buffered channel
[17:04] <katco> natefinch: just ran across that when reading through this code
[17:08] <natefinch> katco: I'm not entirely sure about the reason for all that locking, so I'm not ready to comment on if it should be changed.
[17:08] <katco> natefinch: from the docs: "Package sync provides basic synchronization primitives such as mutual exclusion locks. Other than the Once and WaitGroup types, most are intended for use by low-level library routines. Higher-level synchronization is better done via channels and communication."
[17:09] <katco> natefinch: if we're not using panics b/c it is not idiomatic go, we should not be using mutexes either
[17:09] <natefinch> katco: meh. The go authors have admitted, sometimes a lock is a much simpler solution to a problem
[17:10] <bodie_> mgz, good to go on pull 311?
[17:10] <katco> natefinch: that seems like a double standard to me
[17:13] <natefinch> It's a pragmatic standard.  Using channels can complicate code where it's not really necessary.  Panic *always* complicates code... and causes your implementation to leak into the caller's code.  Callers of code that uses mutexes don't ever need to know you're using a mutex unless you expose it.
[17:14] <katco> natefinch: although i disagree about panics (exceptions), there is the same argument for channels
[17:15] <katco> natefinch: callers need never know how you've implemented synchronization
[17:25] <natefinch> katco: You're welcome to take it to juju-dev.  I think it's good to want to make our code more idiomatic.
[17:25] <natefinch> (juju-dev the mailing list that is)
[17:25] <katco> natefinch: i'd like to once i'm a little more settled. i just thought you'd be interested since we had been discussing it
[17:26] <katco> hm it doesn't look like my PR was automatically updated with my push... do i close the existing one and resubmit?
[17:26] <natefinch> I think if you just re-PR it'll work
[17:27] <natefinch> sorry, I haven't landed a ton of code since the switch  :/
[17:27] <katco> natefinch: ok (crosses fingers)
[17:27] <katco> natefinch: oh no worries, i gather everyone is still figuring this out
[17:28] <natefinch> I'm sure mgz would know, possibly wwitzel3 or ericsnow too
[17:29]  * natefinch just pings everyone
[17:30] <wwitzel3> :)
[17:30] <ericsnow> katco, natefinch: I've done it a few times at is always works (though I'm pretty sure it you have to refresh the page and it *may* not be instant)
[17:30] <wwitzel3> katco: if you pushed to the same branch, it should of updated it
[17:30] <ericsnow> s/at is/and it/
[17:33] <perrito666> voidspace: ping
[17:34] <katco> ericsnow: wwitzel3: ty gentlemen
[17:35] <bodie_> natefinch, http://paste.ubuntu.com/7810105/
[17:35] <bodie_> seems odd that there's still a dep for binary132/gojsonpointer
[17:40] <natefinch> bodie_: oops, probably my fault
[17:40] <bodie_> natefinch, I grepped for binary132 without result O.o
[17:40] <bodie_> oh, oops, of course
[17:41] <bodie_> yep
[17:41] <bodie_> gojsonreference
[17:42] <bodie_> however, I'm not sure how to PR my fix
[17:42] <bodie_> since it's forked from xeipuuv, when I open the fix branch, it wants to PR against xeipuuv's
[17:44] <bodie_> looks like you can either merge my change by adding my branch as a remote, or just do it yourself, I suppose
[17:44] <bodie_> natefinch, it's just the import in gojsonreference
[17:45] <natefinch> bodie_: yeah, fixing it
[17:46] <natefinch> bodie_: there you go
[17:48] <voidspace> perrito666: pong
[17:49] <voidspace> biab - going jogging
[17:49] <voidspace> sorry perrito666
[17:50] <perrito666> lol, voidspace well talk tomorrow, its just tomake sure I understood correctly your changes to admin password (and how they most likely break old restore)
[17:50] <voidspace> perrito666: https://github.com/voidspace/juju/compare/copy-sessions
[17:50] <voidspace> perrito666: I don't directly change oldPassword
[17:50] <voidspace> perrito666: it's still used in production
[17:50] <voidspace> I haven't changed that
[17:50] <voidspace> or at least, if it's still used it will still work
[17:51] <perrito666> ok
[17:57] <katco> ok https://github.com/juju/juju/pull/319 finally in
[18:08] <rogpeppe> to whom it may concern: i'm around this evening (for the next 2 hours) if anyone needs to ask any juju-core questions
[18:15] <bodie_> natefinch, sorry, just about done here, things got a little madcap here chez bodie
[18:30] <bodie_> natefinch, https://github.com/juju/juju/pull/329
[18:34] <natefinch> bodie_: why does that change juju/charm?
[18:35] <bodie_> because that's where the gojsonschema dependency is
[18:35] <natefinch> bodie_: ahh I see
[18:35] <bodie_> natefinch, specifically, gojsonschema is used to validate against charm.ActionSpec
[18:35] <bodie_> so, anywhere we're validating, we're doing so against that type
[18:36] <bodie_> using a method on the type
[18:36] <bodie_> I took the liberty of merging the import fix to charm since it tests OK
[18:37] <natefinch> bodie_: cool
[19:01] <natefinch> rick_h__: ping on the MaaS nuc stuff
[19:01] <rick_h__> natefinch: sure thing, I'll pull my list together
[19:01] <natefinch> rick_h__: thanks
[19:08] <rick_h__> natefinch: https://pastebin.canonical.com/113747/ is what I picked up
[19:09] <rick_h__> natefinch: and I got a usb -> ethernet adapter for the maas controller so that it's dual homed on both the external network (for the team to access) and the private on the switch for the maas network to operate
[19:12] <rogpeppe> anyone fancy a review of the brand-new fresh-off-the-press charm store HTTP router: https://github.com/juju/charmstore/pull/14
[19:22] <natefinch> rick_h__: awesome, thanks
[19:25] <alexisb> alrighty all I am out of here! see you in a week
[19:26] <natefinch> alexisb: have fun!
[19:26] <natefinch> alexisb: we'll keep the place from burning all the way to the ground while you're gone
[19:27] <alexisb> :)
[19:27] <alexisb> I believe you natefinch
[19:27]  * perrito666 is surprised by natefinch comment while he fetches gas and a match
[19:27] <bodie_> I'm sure there won't be any freak gasoline fight accidents.
[19:27] <rick_h__> alexisb: have a good time, but did reply to your email :P light reading for the trip
[19:28] <alexisb> rick_h__, thanks
[19:28] <alexisb> btw rick_h__ good stuff that is very helpful
[19:29]  * perrito666 begins the burning
[19:31] <natefinch> I
[19:31] <natefinch> I'd really love it if canonical hr would stop logging me out and deleting my in-progress reviews
[19:31] <perrito666> well I only did one, but that did not happen to me
[19:32] <natefinch> If you stay on the review page for too long "save and continue" means "dump you to ubuntu SSO and then redirect to the salesforce main page"
[19:32] <perrito666> how fun... not
[19:34] <natefinch> note that none of that includes actually saving your work
[19:34] <perrito666> natefinch: try ctrl+click
[19:35] <perrito666> if properly coded should try to do that on the next tab
[19:35] <natefinch> if....
[19:35] <perrito666> so there you can go by with the re-login and then re save
[19:35] <natefinch> I'll give it a try
[21:10] <katco> wallyworld: i have to run to a preschool orientation, but i added some details to the card for the kvm stuff. i wouldn't mind you taking a look to see if i'm on the right track if you have any free time.
[21:12] <katco> EOD, ciao!
[22:08] <wallyworld> voidspace: if you're still around, how's the mgo session stuff?
[22:13] <wallyworld> thumper: have you started looking at the container issues?
[22:13] <thumper> wallyworld: no, have to do hr stuff that I'm already behind on
[22:14] <wallyworld> thumper: yeah, i'm behinf also :-(
[22:14] <wallyworld> i'll start looking but may need your input
[22:14] <wallyworld> i alswo goota do a tonne or hr
[22:34] <voidspace> wallyworld: hey, hi
[22:34] <voidspace> wallyworld: soooo...
[22:34] <wallyworld> hey
[22:35] <voidspace> wallyworld: I did some more, completed the transaction runner and a few more collections in the watcher replaced with session copying
[22:35] <voidspace> https://github.com/voidspace/juju/compare/copy-sessions
[22:35] <voidspace> with an mp for juju/txn
[22:35] <voidspace> https://github.com/juju/txn/pull/1/files
[22:35] <voidspace> wallyworld: I was searching around looking at all the places that need to change and it was a bit daunting
[22:36] <voidspace> because state.State is basically a big bag of collections that need to be copied any time they're used
[22:36] <wallyworld> yep :-(
[22:36] <voidspace> and whilst I was jogging a better solution occurred to me
[22:36] <voidspace> as we shouldn't be reusing those collections they just shouldn't be stored on State
[22:36] <wallyworld> i agree
[22:37] <voidspace> instead a method that fetches the collection for you when you need it - then we can *ensure* that every time they're touched you have a new session
[22:37] <voidspace> and the compiler will tell me all the places to fix
[22:37] <voidspace> so I won't miss any
[22:37] <wallyworld> yep
[22:37] <voidspace> so I'm about to do that now
[22:37] <voidspace> unfortunately it makes a little bit of my work so far redundant
[22:37] <wallyworld> i think an email to gustavo may be useful just to ensure the right approach is being used
[22:37] <voidspace> but I have a couple of useful functions I put in the mongo namespace
[22:38] <voidspace> niemeyer: ping - I don't suppose you're still around are you?
[22:38] <voidspace> wallyworld: ok, I have an email I started
[22:38] <wallyworld> i'd like to understand why it was done the way it was in the first place
[22:38] <wallyworld> considering it seems wrong
[22:38] <wallyworld> maybe we're missing something
[22:38] <voidspace> wallyworld: my initial idea was to replace all the collection references with methods to fetch the collection
[22:38] <voidspace> but there's no need for it
[22:38] <voidspace> but I started an email about it anyway
[22:39] <voidspace> wallyworld: so the current revision is a useful point - all tests pass
[22:39] <wallyworld> \o/
[22:39] <voidspace> and I'm about to embark on the "grand delete"
[22:39] <wallyworld> i do thing removing the collections from state is the right approach
[22:39] <voidspace> I'll send the email, but then just begin anyway
[22:39] <voidspace> and if it turns out not to be wise we can just go back a few revisions
[22:39] <wallyworld> seems more in line with the expectedusage patterns
[22:39] <voidspace> yep
[22:39] <wallyworld> thank you
[22:40] <voidspace> leaving the collections there is dangerous
[22:40] <wallyworld> yep, i hate essentially global state like that
[22:40] <voidspace> you only need to have one place that uses the global session to be at risk (extra risk anyway) of timeout
[22:40] <voidspace> yep
[22:40] <voidspace> so we have one global session - but we basically use that just to store connection details
[22:40] <voidspace> for session copying (which is using socket pooling under the hood anyway)
[22:40] <wallyworld> yep, that is how these things are normally architected
[22:41] <wallyworld> cahce the credentials, peel off a new session from a pool when needed
[22:41] <wallyworld> hence i'd like to see if we're missing anything give tne implementation as it is now seems wrong
[22:41] <voidspace> and deleting those State collections nicely leverages the compiler to tell me when I've found all the places using them
[22:41] <voidspace> yeah, no idea
[22:41] <wallyworld> yes indeed
[22:42] <voidspace> but gustavo *agrees* it's wrong and wants the change
[22:42] <wallyworld> ok
[22:42] <wallyworld> in that case jfdi :-)
[22:42] <voidspace> and he said the right approach was to copy the session, deferring close, every time you do something
[22:42] <voidspace> so, going downstairs to do it whilst watching vikings :-)
[22:42] <voidspace> back online in a minute
[22:42] <wallyworld> this will be a nice win - delete global state (shudder), fix stale sessions yada yada
[22:43] <voidspace> there will probably be other places in the code that need work
[22:43] <voidspace> we can grep for mgo.Collection and session
[22:43] <voidspace> I had a look at a few - but some of those are innocent (like using the session immediately after creating it is fine I think)
[22:56] <wallyworld> i thik so too, so long as we don't then just hang on to that session and try and use it again later without a clone
[22:56] <voidspace> right
[23:02] <voidspace> so, "go build ./..." reports a few errors
[23:02] <voidspace> followed by
[23:02] <voidspace> state/addmachine.go:713: too many errors
[23:02] <voidspace> I guess I fix them a few at a time...
[23:02] <wwitzel3> voidspace: yeah I never figured out a way to get all of them
[23:02] <voidspace> wwitzel3: seeing them all would be very depressing I think
[23:02] <voidspace> a few at a time is probably the way to go...
[23:02] <voidspace> :-)
[23:12] <voidspace> wallyworld: we have a lot of code like
[23:12] <voidspace> a.st.units.Name
[23:12] <voidspace> where st is state and units is the "units" collection
[23:12] <wallyworld> yes we do
[23:12] <voidspace> isn't Name *always* going to be "units"?
[23:12] <wallyworld> i think so yes ottomh
[23:13] <voidspace> ottomh?
[23:13] <wallyworld> off the top of my head
[23:13] <voidspace> hah
[23:13] <voidspace> thanks
[23:13] <wallyworld> :-)
[23:13] <mwhudson> off the top of my head
[23:13] <mwhudson> doh
[23:13] <voidspace> rather than copy the session and get a new collection I'm going to hardcode the name
[23:13] <mwhudson> was scrolled up :)
[23:13] <voidspace> and see what happens
[23:13] <voidspace> mwhudson: morning
[23:13] <voidspace> mwhudson: what are you doing here?
[23:14] <mwhudson> voidspace: i was involved in the juju on arm64 stuff and haven't left yet!
[23:14] <voidspace> hah
[23:14] <voidspace> cool
[23:14] <voidspace> I'm doing surgery
[23:45] <thumper> that moment when you hear a crash followed by the words "don't move, there is glass everywhere"...
[23:47] <voidspace> oh dear
[23:47] <voidspace> thumper: how was tinkerbell?
[23:49] <thumper> voidspace: one said "I literally died", I told her it only "figuratively or metaphorically died"
[23:49] <thumper> the elder said it was 87 minutes of pure pain and 3 minutes of awesome
[23:49] <voidspace> hehe
[23:49] <thumper> youngest said "meh"
[23:49] <thumper> and she was the one that wanted to see it
[23:49] <thumper> so, not wonderful
[23:49] <voidspace> my goodness, that's quite a collection you have
[23:49] <voidspace> I shall knock it off my "must see" list then...
[23:49] <thumper> heh
[23:53] <voidspace> thumper: do you know any reason, beyond a desire not to hardcode strings, to do "state.cleanups.Name" instead of just "cleanups" ?
[23:53] <voidspace> thumper: our code is littered with them (accessing column names via the columns - where we know the name)
[23:54] <thumper> voidspace: got a concrete example?
[23:54] <voidspace> state/cleanup.go line 88
[23:54] <voidspace> thumper: there are tens of such examples
[23:55] <voidspace> possibly a hundred, I don't know because the compiler just says "too many errors"...
[23:56] <thumper> these are collections not columns
[23:56] <thumper> but no, I think it is just to avoid magic strings
[23:57] <thumper> voidspace: where is it initialized?
[23:57] <voidspace> thumper: it's a state.State member created in state.Open (state/open.go) with db.C("cleanups")
[23:59] <thumper> personally I'd rather have a package level constant: const cleanupCollection = "cleanups"
[23:59] <thumper> and use that in state.Open, and in the collection descriptions
[23:59] <thumper> but I can see how it started :)
[23:59] <voidspace> thumper: well, I'm removing all those collections from state
[23:59] <thumper> I bet it just grew organically from the first use