[00:26] <davecheney> thumper: // InitializeFromConfig needs to be called once after the environment
[00:26] <davecheney> func InitializeFromConfig(config PreferIPv6Getter) { globalPreferIPv6 = config.PreferIPv6() logger.Infof("setting prefer-ipv6 to %v", globalPreferIPv6)
[00:26] <davecheney> }
[00:26] <davecheney> urgh
[00:26] <davecheney> http://paste.ubuntu.com/13356006/
[00:26] <davecheney> this method does not do what it's comment says
[00:26] <thumper> wa?
[00:26] <davecheney> it initalises nothing
[00:26] <davecheney> unless it's a side effect of calling config.PreferIPv6
[00:27] <thumper> davecheney: it sets the global variable
[00:27] <thumper> globalPreferIPv6 = config.PreferIPv6()
[00:28] <davecheney> oh fuck
[00:28] <davecheney> welp, there's another data race
[00:30] <davecheney> really ?
[00:35] <perrito666> davecheney: can we call you "the prolific dave cheney" from now on?
[00:36] <perrito666> http://features.slashdot.org/story/15/11/18/1748247/interviews-alan-donovan-and-brian-kernighan-answer-your-questions <-- for those who have not seen it, dave is featured in a Q&A by D&K
[00:40] <davecheney> \o/
[00:40] <davecheney> i have to be honest
[00:40] <davecheney> i never read that post
[00:40] <davecheney> it was full of toxic slashdotters
[00:40] <davecheney> maybe I should try again
[00:42] <perrito666> Nothing new but you are named as a proposer of the solution to version handling in go pks
[00:43] <davecheney> orly
[00:43] <perrito666> The rest of the questions are same old ones
[00:43] <davecheney> i should *definitely* read that then :)
[00:44] <wwitzel3> how often does the upgrade watcher cycle?
[00:52] <thumper> davecheney: I want to change s/Opener/APIOpener/ back, as envcmd.Opener doesn't really describe it, but envcmd.APIOpener does a bit more
[00:52] <thumper> davecheney: can you live with that?
[00:53] <davecheney> thumper: sure
[00:54]  * thumper move back to sitting deck
[01:12] <axw> wallyworld_: I'm back, free to chat whenever you're ready
[01:13] <wallyworld_> axw: ok, i have another meeting in 15 and need to do some other stuff also so best to wait to our schedule time
[01:13] <axw> wallyworld_: nps
[02:36] <davecheney> thumper: menn0 https://github.com/juju/juju/pull/3785
[02:45] <thumper> davecheney: shipit
[02:46] <davecheney> ta
[03:06] <cherylj> hey menn0, are you going to make the change to TestFilesystemInfo?  or are you still waiting on input from mwhudson?
[03:18] <davecheney> thumper: menn0 http://juju-ci.vapour.ws:8080/job/github-merge-juju/5520/console
[03:18] <davecheney> here is a great example of why always using etsting.BaseSuite is a bad idea
[03:19] <davecheney> in this case the test has failed because testing.Base suite also sets up some networking crap
[03:19] <davecheney> even though the test is just checking did something get written to the log at trace level
[03:20] <natefinch> it boggles my mind that we have tests that depend on the log output.
[03:20] <mgz> ...?
[03:21] <mgz> it makes sense to tese your logging isn't crap
[03:21] <mgz> it doesn't make sense to do that at a functional test
[03:24] <natefinch> there are some very specific circumstances where you would want to unit test some logging, I can understand that.   But it should be the exception rather than the rule.... and we have a ton of tests that'll fail if you disable logging (I know, I tried it back when I tried to make our failed test output not so horrific)
[03:26] <davecheney> completely bonkers
[03:27] <natefinch> we have a bad habit in juju tests of testing crap we really don't actually care about, so our tests are brittle, and break for ridiculous reasons, like fixing typos
[03:28] <davecheney> for example
[03:28] <davecheney> we have a method to set a global singleton to true, or false
[03:28] <davecheney> and a third method that set it to false, but doens't log that's done anything
[03:28] <davecheney> da fuq
[03:29] <davecheney> and tests that rely on this behaviour
[03:32] <davecheney> while i'm having a rant
[03:32] <davecheney> i'm really pissed that all the test break if you don't have LXD installed
[03:32] <davecheney> and not in a
[03:32] <davecheney> c.FailNow("You don't have LCD installed")
[03:32]  * natefinch hangs head.
[03:33] <davecheney> they fail because something in the guts of the code the test is calling is shelling out to /usr/bin/lxd
[03:33] <davecheney> and trying to parse the output
[03:33] <davecheney> really shit
[03:33] <natefinch> Sorry, yeah, we should fix that.
[03:34] <natefinch> I'll file a bug for it.  Just didn't think of it, since we'd all installed LXD in order to be hacking on it.
[03:34] <davecheney> thanks
[03:35] <davecheney> i already logged a bug about the lxd provisioner failing horribly whne lxd is not installed
[03:35] <davecheney> natefinch: open question: how did this pass in CI ?
[03:35] <natefinch> / +build go1.3
[03:35] <natefinch> :p
[03:36] <natefinch> the lxd library uses some tsl function that's only in go 1.3+
[03:36] <natefinch> tls
[03:36] <natefinch> so the answer is... the tests don't get run in go 1.2... I don't know what happens on the wily build machine
[03:37] <natefinch> eric and wayne were handling most of that
[03:37] <natefinch> (and wily is still non-voting due to go 1.5 problems)
[03:38] <davecheney> natefinch: that means the tests are not being run by the landing bot
[03:39] <natefinch> davecheney: yes
[03:39] <davecheney> bummer
[03:39] <natefinch> indeed.   We all wear these now: https://cdn.shopify.com/s/files/1/0287/4374/products/DSC_8422_1024x1024.jpg?v=1411004337
[03:40] <cherylj> natefinch: should we buy those for the sprint?
[03:40] <davecheney> i'll have one in large thanks
[03:40] <davecheney> make mine extra black
[03:40] <davecheney> like my soul
[03:40] <natefinch> lol
[03:40] <cherylj> davecheney is so emo
[03:40] <davecheney> pain, etc
[03:42] <natefinch> also, this makes me so very sad:
[03:42] <natefinch> /home/nate/src/github.com/juju/juju$ grep -r "ErrorMatches" . | wc -l
[03:42] <natefinch> 2848
[03:43] <natefinch> are there 2800 places where we care what the (more or less) exact error message is?  I doubt it.
[03:44] <davecheney> make that two jumpers
[03:49] <natefinch> does anyone even look at the bugs filed on charms?
[03:51] <natefinch> the wordpress charm is fundamentally broken for people who actually want to like, you know, use wordpress (not just show the login screen).  I reported a bug about it 2 months ago and the bug hasn't even been triaged.
[03:52] <natefinch> https://bugs.launchpad.net/charms/+source/wordpress/+bug/1491995
[03:52] <mup> Bug #1491995: Can't upload files to wordpress <wordpress (Juju Charms Collection):New> <https://launchpad.net/bugs/1491995>
[05:23] <Michael_temp> anybody?
[07:07] <mup> Bug #1488523 changed: Azure provider attempts to reuse dying vnet <azure-provider> <bootstrap> <ci> <destroy-environment> <reliability> <repeatability> <juju-core:Won't Fix> <https://launchpad.net/bugs/1488523>
[07:07] <mup> Bug #1494002 changed: azure deployment failure with mem constraints <azure-provider> <constraints> <deploy> <juju-core:Won't Fix> <https://launchpad.net/bugs/1494002>
[10:01] <voidspace> dimitern: stdup?
[10:02] <dimitern> voidspace, omw, 2m
[10:30] <voidspace> frobware: https://github.com/juju/juju/pull/3788/files
[10:30] <voidspace> dimitern: https://github.com/juju/juju/pull/3788/files
[10:42] <voidspace> frobware: I do have test failures on that rebase branch but they're "weird"
[10:43] <voidspace> frobware: can you run tests on that branch please
[10:43] <frobware> voidspace, yep
[10:54] <voidspace> frobware: all tests are passing so far on maas-spaces (as is) for me, so new failures are probably genuine :-/
[10:54] <voidspace> might be worth you re-trying the rebase locally and seeing if you get the same result
[10:59] <frobware> voidspace, that's what I was initially doing.
[11:02] <voidspace> maas-spaces is all pass for me
[11:03] <voidspace> trying master now
[11:12] <frobware> voidspace, I rebased maas-spaces against master; make check works for me too
[11:14] <voidspace> frobware: I'm getting test failures on master - at least some lxd related
[11:14] <voidspace> so that maybe the problem
[11:15] <frobware> voidspace, scrolling back through the chat there is mention of tests failing & (lack of) lxd installation
[11:16] <frobware> voidspace, but given our rebase attempt they should fail in the maas-spaces branch as well... ?
[11:16] <voidspace> container_initialisation_test.go fails on master for me too
[11:16] <voidspace> as far as I can see the tests that fail on the rebase fail on master for me too
[11:17] <voidspace> so should be ok
[11:17] <voidspace> other than tests failing on master being a problem!
[11:17] <voidspace> I'm installing lxd...
[11:25] <frobware> voidspace, master is OK for me. I don't have lxd installed.
[11:49] <voidspace> frobware: I'm on wily, I wonder if that's it
[11:49] <voidspace> installing lxd doesn't make a difference
[11:56] <voidspace> frobware: so do tests pass for you on my rebase branch?
[11:56] <voidspace> if so I'll merge it
[11:57] <frobware> voidspace, let me try your branch
[12:01] <frobware> voidspace, ah. so wily will be go-1.5.
[12:02] <voidspace> frobware: no, I'm using go 1.3.3
[12:02] <voidspace> I thought lxd provider required go 1.5
[12:02] <voidspace> hmmm, it used to - maybe that changed
[12:02] <voidspace> it all builds ok without 1.5
[12:03] <frobware> I have a wily plaground and `apt-get install golang-go' gives me 1.5. Are you building or using your own go build?
[12:04] <voidspace> frobware: yes :-)
[12:12] <voidspace> dimitern: frobware: so some of my failing tests on *my WIP branch* (not the rebase branch) were because with the addition of Spaces to NetworkingEnviron the dummy provider was no longer "supporting networking"
[12:12] <voidspace> dimitern: frobware: so that's an easy fix
[12:12] <voidspace> thank goodness
[12:12] <dimitern> voidspace, alright!
[12:13] <dimitern> voidspace, nice :)
[13:41] <fwereade> goddammit just as I am properly getting into something I have to go out for a while -- back this evening
[13:41] <perrito666> gluck
[14:39] <perrito666> does anyone know if a maas can be done whith storage from a nas instead of having each machine have storage?
[14:56] <maht> I am maas newbie, but I guess you would need to create a custom image that use the NAS as remote filesystem
[15:14] <mup> Bug #1518347 opened: LXD tests require LXD, but there's no friendly "you don't have LXD" error message <juju-core:New> <https://launchpad.net/bugs/1518347>
[15:20] <mup> Bug #1518347 changed: LXD tests require LXD, but there's no friendly "you don't have LXD" error message <juju-core:New> <https://launchpad.net/bugs/1518347>
[15:23] <mup> Bug #1518347 opened: LXD tests require LXD, but there's no friendly "you don't have LXD" error message <juju-core:New> <https://launchpad.net/bugs/1518347>
[15:26] <mup> Bug #1518347 changed: LXD tests require LXD, but there's no friendly "you don't have LXD" error message <juju-core:New> <https://launchpad.net/bugs/1518347>
[15:43] <voidspace> I have lxd installed, but get lots of test failures "can't connect to the local LXD server"
[15:43] <voidspace> (permission denied)
[15:52] <natefinch> voidspace: weird. we're in a meeting now.  what series are you on?
[16:03] <frobware> voidspace, you still about? did we rebase?
[16:37] <lazypower> o/ - can someone lend a hand in clueing me in as to the purpose/case for JUJU_ACTION_TAG is?
[16:37] <lazypower> it appers to be a copy of JUJU_ACTION_UUID with the word "action" prepended, and thats the only discernable difference
[17:57] <fwereade> lazypower, um, don't use it
[17:57] <fwereade> lazypower, we probably never should have exposed it
[17:57] <fwereade> lazypower, tags are meant to be homogeneous ids for the api layer
[18:02] <voidspace> natefinch: I'm on wily
[18:03] <voidspace> frobware: I didn't merge - I don't get a clean test run on master so it's not easy to tell if the merge works
[18:03] <frobware> voidspace, ack
[18:06] <frobware> voidspace, upstream/maas-spaces rebased seem to be OK though.
[18:12] <voidspace> frobware: did you try my branch?
[18:12] <voidspace> frobware: if tests pass on that I'll merge it
[18:12] <voidspace> frobware: https://github.com/juju/juju/pull/3788
[18:16] <frobware> voidspace, well they did about 10am... :)
[18:16] <frobware> voidspace, I need to EOD in a bit. If you don't need this until Monday I could double-check again and then merge.
[18:17] <voidspace> frobware: hah, I was waiting for you to tell me you'd tried it...
[18:17] <voidspace> :-p
[18:17] <frobware> voidspace, I did at 10am.
[18:17] <voidspace> frobware: no hurry, Monday is ok
[18:17] <voidspace> frobware: although I haven't touched that branch since, so if they passed then they'll pass now
[18:18] <frobware> voidspace, I subsequently noticed later in the day I was using go 1.5 for that build so I should try again with 1.2.
[18:18] <voidspace> frobware: I think the CI bot will try with 1.2
[18:18] <voidspace> frobware: I've hit $$merge$$ anyway
[18:18] <frobware> good point
[18:18] <voidspace> natefinch: I'm using wily but using go 1.3
[18:40] <alexisb> voidspace, lxd needs at least 1.3, for the lxd provider juju builds with what is in wily 1.5
[18:41] <alexisb> voidspace, not sure if that helps
[18:47] <natefinch> go 1.3 should work fine. I usually build with 1.4.2, just because it's the newest non-1.5 build (and the 1.5 builds are significantly slower).
[18:47] <natefinch> wonder if it's a wily thing
[18:51] <voidspace> alexisb: thanks, I have 1.3
[18:51] <voidspace> it builds fine but I have test failures
[18:52] <alexisb> voidspace, related to this: https://bugs.launchpad.net/juju-core/+bug/1517748
[18:52] <alexisb> ??
[18:52] <mup> Bug #1517748: provider/lxd: test suite panics if lxd not installed <juju-core:Triaged> <https://launchpad.net/bugs/1517748>
[18:52] <voidspace> alexisb: see my comment on that bug
[18:53] <alexisb> aah I hadn't refreshed
[18:53] <voidspace> frobware: test failures for that merge, hard to see if they're the same or related or spurious or what
[18:53] <voidspace> frobware: http://juju-ci.vapour.ws:8080/job/github-merge-juju/5525/console
[18:53] <katco> voidspace: we will be addressing that next week. are you sure you're on tip of master?
[18:53] <voidspace> katco: I was a couple of hours ago...
[18:54] <voidspace> katco: I have lxd installed and still have test failures though
[18:54] <voidspace> katco: so not *entirely* sure it's the same bug
[18:54] <katco> voidspace: is your user in the lxd group?
[18:55] <voidspace> katco: yep
[18:55] <voidspace> I gotta go, 7pm here and guests arriving
[18:55] <voidspace> EOW, sorry
[18:55] <katco> voidspace: np ty for input
[18:55] <katco> voidspace: we'll get it fixed enxt week
[18:56] <voidspace> katco: cool, thanks
[18:56] <frobware> cherylj, I pretty sure I understand why the bond and juju-br0 don't work. Need to futz with our script a bit -
[18:57] <cherylj> frobware: ah, good to hear!
[18:57]  * frobware EOF -- that's End of Friday. :)
[19:09] <rick_h_> frobware: have fun!
[19:18] <katco> natefinch: hey you're going to make sure the min-version branch has a bless before you land it into master, correct?
[19:19] <natefinch> katco: yeah, good point.  I'll move it into a feature branch so it can get CI'd.
[19:19] <katco> natefinch: k
[19:20] <natefinch> katco: it's really not a hugely sweeping change by any stretch of the imagination, but I think it pays to be overly careful given the problems of the recent past.
[19:20] <katco> natefinch: not even a question of impact, it's just policy
[19:23] <natefinch> katco: fair enough
[19:36] <katco> natefinch: talk to mgz or sinzui to see if you can get the next ci run to hit it
[19:37] <mgz> natefinch: I can push your branch into the juju namespace if you need that
[19:46] <natefinch> mgz: that would be very helpful
[19:47] <natefinch> mgz: it's the minver branch on github.com/natefinch/juju
[19:50] <mgz> natefinch: doing it
[20:06] <mgz> natefinch: you are in and up next
[20:07] <natefinch> mgz: thanks
[20:11] <natefinch> rogpeppe3: are you actually here?
[20:35] <natefinch> gah, I really hate it when people leave juju/juju in a state where it can't build against master of its dependent branches.  it means I have to fix the build before I can land anything
[21:48] <natefinch> well, not getting juju min version in today it seems.
[21:49] <katco> natefinch: =/ b/c of the libs ?
[21:50] <natefinch> katco: yeah.  I can land the stuff in charm.v6, but the stuff in master won't be able to go in without fixes first... axw has what might be the fixes on a personal branch, but they're slightly above trivial, so I wouldn't want to touch them without talking to him
[21:51] <katco> natefinch: makes sense. well at least you have ci building against your branch
[21:52] <natefinch> katco: yeah, but I don't think I can make my branch compile for CI, even
[21:54] <natefinch> katco: it works locally because I can hack things so that my commits are against an earlier version of charm.v6, but it can't be set up to run in Ci where it runs godeps
[21:55] <katco> natefinch: oh. doh.
[21:55] <katco> natefinch: well, once your fix to charm.v6 lands, you can patch your feature branch to use that version and run ci, yeah?
[21:56] <natefinch> katco: this is the whole problem... landing the code in charm.v6 means landing after those breaking changes
[21:57] <natefinch> katco: I fcan make it work locally because I can make a local branch off an earlier version of charm..v6 that excludes the breaking changes... but I can't create that kind of a branch in github.com/juju/charm
[21:57] <natefinch> (I mean, In theory an admin could, but it would be a heinous thing to do)
[21:58] <natefinch> I'll update my email to indicate that it's not just master but my feature branch that has this issue.
[21:58] <katco> natefinch: sorry, not sure i understand. you're landing some fixes in charm.v6, why couldn't you patch up your feature branch to be compatible with those changes?
[21:59] <natefinch> katco: oh, I could. They're just slightly beyond trivial... so I wouldn't want to get my feature branch in a bad state if I mess up those fixes
[21:59] <natefinch> katco: if I talk to andrew and confirm that I just need to cherry picky a couple commits, then yeah, I can do that.
[21:59] <katco> natefinch: oh i think i see.. you'd have to apply axw's changes to your feature branch and that is non trivial
[21:59] <natefinch> correct
[21:59] <katco> gotcha
[22:00] <katco> natefinch: can you rebase your feature branch to a blessed version of master?
[22:00] <katco> natefinch: at least then you've utilized your "dead time" and tested up to that point
[22:01] <natefinch> katco: yes, but the problem is in charm.v6, so it would still be there.  The solution could be to make a feature branch in charm.v6 off the earlier blessed version
[22:01] <katco> natefinch: yeah, not a bad use of the "dead time". also looks like mgz just sent an email
[22:01] <katco> natefinch: might have some other stuff to fix up
[22:01] <natefinch> gah, yeah
[22:02] <natefinch> just read it
[22:02] <natefinch> ok, I'll work on that tonight.  Gotta run to make dinner now.
[22:02] <katco> natefinch: have a good thanksgiving
[22:02] <natefinch> katco: you too!
[22:08] <fwereade> hey, do we have a way of flagging long-running tests as not-for-normal-runs?
[22:17] <perrito666> fwereade: I believe we do
[22:44] <fwereade> perrito666, do you happen to know what it might be?
[22:45] <perrito666> fwereade: nope, katco told me a gazillion times and I forgot a gazillion + 1
[22:45]  * fwereade glances hopefully at katco
[22:45] <fwereade> ...although I've almost convinced myself that it's ok to patch just this once
[22:46] <katco> fwereade: o/ is this what you're looking for? https://github.com/juju/juju/blob/master/featuretests/package_test.go#L15
[22:46] <fwereade> katco, I was wondering if there was something that'd work globally
[22:47] <fwereade> katco, but I am being silly anyway
[22:47] <katco> fwereade: oh, no i don't think we've begun flagging certains tests as long or short yet
[22:47] <fwereade> katco, cheers
[22:48] <katco> fwereade: happy friday to you :)
[22:49] <fwereade> katco, and to you :)
[22:49] <fwereade> katco, by the way, do you recall state/testing.NotifyWatcherC et al?
[22:50] <katco> fwereade: not at all... what is it?
[22:50] <fwereade> katco, it's a test harness for a watcher
[22:50] <fwereade> katco, was wondering, if you'd used it, whether you thought it was a sane interface
[22:51] <katco> fwereade: i haven't used it, sorry :(
[22:51] <fwereade> katco, no worries :)
[22:51] <katco> fwereade: however, i do almost have a working charm that starts an emacs web server. so that must count for something.
[22:51] <fwereade> katco, sweet :D
[22:52] <katco> fwereade: this is going to be such an unholy abomination. i love it.
[22:53] <fwereade> katco, in principle, I heartily approve, but please be ready to pull the plug in case skynet
[22:53] <katco> fwereade: it's too late, dear william. it's already gotten to me.
[22:54]  * fwereade welcomes our new robots overlords
[22:56] <perrito666> uh, robot overlords? sweet I could do with a break on all the thinking stuff
[22:57] <katco> perrito666: i was very happy to see you still using emacs in your tweet :)
[22:57]  * perrito666 is as close to burnout as one can be before being actually burnt
[22:57] <perrito666> katco: it totally stuck this time, Just need to get a bit more proficient, but I am on a good path
[22:57] <katco> perrito666: good to hear
[22:58] <katco> perrito666: the packaging system + use-package is a great combination
[22:58] <perrito666> I might use a couple of hours of my holidays to learn a few tricks more
[22:58] <perrito666> and perhaps tune it a little more
[22:59] <katco> perrito666: this is a fun site: http://emacsrocks.com/
[22:59] <perrito666> I see you are not only working in new clients but also in retention :p
[23:00] <perrito666> my next conquest is to try to get a marker in the lines that are not git committed yet, which is a feature I miss a lot
[23:00] <katco> perrito666: i must do as the master suggests.
[23:03] <katco> perrito666: there might be something better, but a quick scan: https://github.com/nonsequitur/git-gutter-plus
[23:04] <perrito666> nice, actually I am going for something simpler, I am completely happy to use the command line for git :p
[23:05] <perrito666> I just want the +, ~ and - next to the line number
[23:05] <perrito666> Ill try all options I find :D
[23:05] <katco> perrito666: i highly recommend magit as a better way to git
[23:05] <perrito666> uhh, sweet, new github design
[23:06] <katco> perrito666: it's so nice. remind me to show you in dec. if you'd like
[23:06] <perrito666> katco: after years of git, I believe a better way to git is not to git at all :p
[23:06] <perrito666> katco: totally, I always dig learning new tools
[23:06] <katco> magit makes so many things much simpler
[23:06] <katco> i think any gui for git might
[23:06] <katco> but it's nice that it's built into emacs
[23:07] <perrito666> katco: Ill be honest here, the only git guis that I liked where for OSX
[23:07] <perrito666> and iirc, commercial :p
[23:08] <katco> magit might change your mind. it is really nice.
[23:08] <perrito666> git and diff displaying in general can benefit a lot from modern graphic paradigms
[23:08] <perrito666> but hey, in linux Ill take what I can get :p
[23:09] <katco> perrito666: with magit, you have a file you need to merge, you cursor down over the file, hit e and you get a side-by-side with merged at the bottom
[23:09] <katco> red/green highlighting, etc.
[23:10]  * perrito666 watches screenshots
[23:11] <perrito666> I really dig stuff like this https://deeperdesign.files.wordpress.com/2011/05/screen-shot-2011-05-27-at-12-59-14-pm.png
[23:12] <katco> perrito666: here's what ediff looks like: http://www.tldp.org/LDP/LG/issue27/gx/marsden/ediff-merge.gif
[23:12] <katco> perrito666: and then you hit a or b depending on which side you want merged
[23:12] <perrito666> is that motif?
[23:12] <katco> lol no idea
[23:13] <katco> the bottom is the merged version
[23:13] <perrito666> blast from the past :p but hey, I have seen worse, ill give it a shot
[23:33] <mup> Bug #1518480 opened: Invalid storage prevents machine removal <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1518480>
[23:33] <mup> Bug #1518482 opened: Invalid storage returned by storage-list causing charm breakage <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1518482>