[00:25] <menn0> wallyworld, thumper: txn pruning improvements http://reviews.vapour.ws/r/1741/
[00:38] <waigani> thumper, axw: storage worker fix: http://reviews.vapour.ws/r/1742/
[00:39] <waigani> I tested 1.23, 1.24, 1.25 - bug is only in 1.24 and 1.25
[00:39] <wallyworld> menn0: done
[00:45] <menn0> wallyworld: thank you. you're a review machine.
[00:46] <wallyworld> sometimes
[00:49] <anastasiamac> menn0: wallyworld is always
[01:05] <axw> waigani: ah, so the state that the agent opens isn't scoped. thanks for looking at that
[01:06] <thumper> waigani: shipit
[01:37] <waigani> thumper, axw thanks - I'll land in 1.24 now and follow up in 1.25
[01:37] <thumper> ack
[01:37] <thumper> waigani: I was just looking at my local machine-0.log wondering why it was 16 meg already
[01:37] <thumper> waigani: was due to the worker constantly restarting in two environments :-)
[01:38] <natefinch-afk> katco: the CI test is working.  It actually inadvertently discovered a bug in lumberjack, due to a combination of how I had to do one of the tests and the fact that destroying the local environment leaves logs behind.
[01:38] <thumper> natefinch-afk: funny how CI tests find bugs eh?
[01:38] <waigani> thumper: ha
[01:40] <natefinch> thumper: yep.  really just a huge coincidence in how everything came together, but I'm certainly glad to find the bug, even if it is a pretty edge case.
[01:41] <natefinch> for those curious: https://github.com/natefinch/lumberjack/issues/12
[01:47] <natefinch> I love how sloppy I can be and let gofmt clean everything up for me.  Saves me a ton of time fiddling with indenting etc
[01:47] <waigani> thumper: hosted upgrades:  http://reviews.vapour.ws/r/1639/ - needs a follow up review (not urgent, I've found another bug to look into)
[01:48] <axw> natefinch: I find I'm much worse about writing in other languages because of that now :/
[01:48] <natefinch> axw: haha yep
[01:49] <waigani> natefinch: +1 if it doesn't format I know I've got a syntax error somewhere, that's been handy too
[01:50] <natefinch> waigani: yep... and in Sublime, if you're using gosublime it'll put a dot next to the line that is invalid
[01:51] <waigani> natefinch: true! too easy :)
[01:56] <menn0> wallyworld, thumper : a quick one before the meeting? http://reviews.vapour.ws/r/1743/
[01:56] <menn0> this is the final bit of the txn pruning work (for 1.22 at least)
[01:56]  * thumper looks
[01:57] <thumper> menn0: if there was no previous, how long does it wait?
[01:58] <thumper> menn0: also, what about those long running ones with 500k transactions pruned
[01:58] <menn0> thumper: that was all in the PR for juju/txn...
[01:58] <menn0> thumper: pruning will first be checked 2 hrs after jujud startup
[01:58] <menn0> thumper: if there is no record of a previous prune, then pruning happens
[01:58] <thumper> k
[01:58] <thumper> well, all that can be tweaked later if necessary
[01:59] <menn0> thumper: there after it only happens when necessary
[01:59] <menn0> thumper: where necessary at the moment means "txn count has doubled since last prune"
[01:59] <thumper> right, just considering the pathalogical cases
[02:00] <menn0> thumper: so for small envs it'll probably never happen
[02:00] <menn0> thumper: or very infrequently
[02:00] <menn0> thumper: for the currently huge envs, they'll have a massive prune the first time around but should then be fairly infrequent
[02:01] <menn0> thumper: there's logging of the txn counts etc in juju/txn each time MaybePruneTransactions is called
[02:25] <natefinch> super quick review anyone?  Just updating dependencies.tsv to include the bugfix I just made to lumberjack: http://reviews.vapour.ws/r/1744/diff/#
[02:26] <natefinch> davecheney: thanks
[02:27] <thumper> axw: machine-0: 2015-05-21 02:26:15 ERROR juju.worker.diskmanager lsblk.go:111 error checking if "sr0" is in use: open /dev/sr0: no medium found
[02:27] <thumper> axw: should I be worried?
[02:27] <axw> thumper: have you pulled trunk lately? that should be fixed a couple of days ago
[02:28] <thumper> axw: no, using jes-cli, behind trunk by a week or two
[02:28] <thumper> axw: good to hear it is fixed though
[02:28] <thumper> I'll merge master soonish
[02:28] <axw> ok, good to know it's probably not still broken :)
[02:29] <perrito666> feature branches feel a bit like the explanation of time travel by the doc to marty
[02:30] <perrito666> in axw and my master is fixed, but in your version of master it is still borken
[02:30] <axw> just need to get the almanac off biff and it'll be OK
[03:04] <natefinch> gah.... just realized my CI test won't work on vivid because it assumes we're using upstart.  le sigh
[03:09]  * natefinch reboots to see if he can get his lxc containers to stop getting stuck for no reason
[03:19] <natefinch> heh... I bet this is that CI blocker that is hosing tip.... let's see if 1.24 works....  yep, that was it.
[03:20]  * natefinch waits for his CI test to write 1.8 GB of data to disk
[03:20]  * natefinch does a little dance
[03:20] <natefinch> success!
[03:23] <natefinch> wallyworld: you around?
[03:23] <wallyworld> yeah
[03:24] <natefinch> wallyworld: there's no docs on status-set on jujucharms
[03:24] <wallyworld> i gave doc to nic
[03:24] <wallyworld> ages ago
[03:24] <natefinch> wallyworld: oh, huh, ok.  I'll bug him then.
[03:24] <wallyworld> ball is in his court
[03:24] <natefinch> evilnickveitch: ^^
[03:25] <wallyworld> not enough hours in the day - we need more doc people
[03:25] <wallyworld> like 2 or 3
[03:25] <natefinch> yep
[03:26] <davecheney> thumper: http://paste.ubuntu.com/11256308/
[03:26] <davecheney> not terrible
[03:26] <davecheney> but some important ones to fix
[04:00] <thumper> davecheney: ack
[04:00]  * thumper tries to work out where to add this test...
[04:03] <cherylj> hey davecheney, quick question for you on your review - I'm not clear how the test case I've added is a race.  We're not actually starting the unit agent, we're just invoking its start method directly.  Is there something I'm missing?
[04:08] <thumper> I wish git stash worked more like bzr shelve
[04:09] <natefinch> what's the difference?
[04:49] <davecheney> cherylj: maybe i was mistaken
[04:50] <davecheney> normally when patch value is used, it's vbecause it's changing the value of a thing that will run in another goroutine
[06:38] <axw> wallyworld: FYI, http://reviews.vapour.ws/r/1751/
[06:38] <wallyworld> looking
[06:51] <axw> ericsnow: the GitHub links in RB seem to be messed up now (looks like unrendered markdown links). did you change something?
[06:53] <axw> wallyworld: I'm going to look at tagging volumes now, since if we don't tag them we won't later be able to list them
[06:54] <wallyworld> axw: yep, sounds great
[06:54] <axw> wallyworld: after that I'll look at persistent volume deletion unless you think there's something more important
[06:54] <wallyworld> axw: i need to go over our cards, we can talk tomorrow
[06:55] <axw> ok
[06:55] <wallyworld> but if you get done before we talk, then vol deletion sounds good
[07:18] <wallyworld> axw: i think the other good card would be storage reattachment?
[07:18] <wallyworld> maybe before volume deletion?
[07:30] <axw> wallyworld: ok
[07:32] <dimitern> voidspace, hey there
[07:32] <dimitern> voidspace, i'm in the hangout
[07:34] <voidspace> dimitern: omw
[07:55] <mfoord> dimitern: and back...
[07:55] <mfoord> dimitern: need to reconfigure virt-manager before I try that again...
[07:55] <TheMue> morning o/
[07:55] <mfoord> TheMue: o/
[07:56] <dimitern> :) ok
[07:56] <dimitern> morning TheMue
[07:56] <TheMue> mfoord: no voidspace today?
[07:56] <mfoord> TheMue: heh
[07:56] <mfoord> TheMue: I had to force kill my machine - virt-manager wouldn't release the mouse and keyboard
[07:56] <dimitern> aaargh.. RB hates me today
[07:56] <dimitern> https://github.com/juju/juju/pull/2392 - reviewers welcome
[07:56] <TheMue> mfoord: ah, ok
[07:57]  * TheMue starts the day with a review
[08:32] <TheMue> dimitern: reviewed
[08:33] <dimitern> TheMue, ta!
[08:34] <TheMue> dimitern: I like the proper use of LXC... instead of Lxc... ;)
[09:00] <mfoord> dooferlad: TheMue: we're going to be a few minutes late to standup - in another meeting
[09:00] <mfoord> dooferlad: TheMue: that is dimitern and I
[09:00] <TheMue> ok
[09:05] <dimitern> mfoord, when you're ready
[09:05] <mfoord> dimitern: TheMue: dooferlad: I'd like to grab a drink
[09:05] <mfoord> 5 mins
[09:09] <mfoord> TheMue: dooferlad: dimitern: right, ready
[09:10] <TheMue> mfoord: we're in
[09:10] <mfoord> omw
[10:55] <jam> menn0: about the pruning changes, you're not tracking the history of successful GC runs and how much they pruned?
[10:55] <jam> You just overwrite 'last' each time
[10:56] <menn0> jam: yep, that's intentional
[10:56] <menn0> jam: I thought we decided it wasn't that important
[10:57] <jam> menn0: I don't think it is critical, but I do think when adding something new like this being able to see how its working is pretty useful.
[10:57] <menn0> jam: well there's still the logs
[10:58] <jam> menn0: unless they have DEBUG logging on and it only captures 5hrs before it rotates.
[10:58] <menn0> jam: sure
[10:59] <menn0> jam: if you feel strongly about it i can change it
[11:02] <jam> menn0: I feel like having that information isn't going to be an OPs problem unless we have something else that's really wrong, and would give us some feedback as to how GC is working in the wild.
[11:08] <menn0> jam: i see your point
[11:10] <menn0> jam: i'll try and get something in tomorrow (it's late here)
[11:11] <jam> menn0: rest well
[11:11] <menn0> jam: i guess you also want the start timestamp and the start txn count? :)
[11:11] <jam> menn0: yeah, so we know Why we tried to run GC, how much GC helped, and how long GC took to run.
[11:11] <menn0> jam: what about the issue of the txns.prune collection growing forever?
[11:11] <menn0> jam: I guess the growth rate is pretty small
[11:11] <jam> menn0: if it grows by 1 record every 2 weeks, and that record is 200bytes in size
[11:12] <jam> we consume 1MB in...
[11:12] <jam> menn0: 192 years
[11:12] <jam> menn0: I can live with that growth rate.
[11:13] <menn0> jam: hmmm I don't know... :)
[11:46] <wallyworld> jam: did you have an opinion on the latest emails re: relation status?
[11:49] <jam> wallyworld: I'll reply, I don't have particularly strong feelings, nor was I in the conversations in Nuremberg
[11:59] <wallyworld> jam: np, i like your input because 99.99999% of the time you are usually right on the money with what should be done :-)
[12:58] <dimitern> reviewers, please have a look at http://reviews.vapour.ws/r/1756/ - fixes bug 1456989 for 1.24
[12:58] <mup> Bug #1456989: cloud-init 0.6.3 on precise generates invalid apt-get install command line <cloud-init> <precise> <regression> <juju-core:Triaged by dimitern> <juju-core 1.24:In Progress by dimitern> <https://launchpad.net/bugs/1456989>
[13:35] <natefinch> linux peeps... I'm trying to set gopath in my install hook... but nothing seems to work.. anyone have any ideas on how to do this?  I tried echo "export GOPATH=$HOME" >> .bashrc  (and same to .profile).... no matter what I do, "go get ..." running in my start hook always says GOPATH not set.
[13:35] <natefinch> (er sorry, that's ~/.bashrc of course)
[13:36] <perrito666> natefinch: I am not sure .bashrc is used for the hooks env
[13:36] <tvansteenburgh> are you sourcing the file after you do that?
[13:37] <natefinch> tvansteenburgh: can I usefully source a file from inside a hook script?
[13:37] <perrito666> natefinch: also, when you speak of your ~ where exactly is that?
[13:37] <perrito666> natefinch: yes, you can, it is a shell after all
[13:38] <dimitern> mfoord, dooferlad, TheMue ^^
[13:38] <dimitern> (the review I posted a while ago)
[13:38] <TheMue> dimitern: ic, will review
[13:38] <natefinch> perrito666: I dunno... where-ever it is.  I presume ~ is the same for the user is running every hook
[13:38] <dimitern> TheMue, thanks!
[13:39] <perrito666> ah you are doing that IN the hook, while running it
[13:39] <perrito666> natefinch: why dont you just run the export?
[13:40] <natefinch> perrito666: it doesn't work if I just export it
[13:40] <tvansteenburgh> he needs it in a later hook right?
[13:40] <perrito666> natefinch: that is... wrong somehow
[13:40] <natefinch> perrito666: go get <thingy> says "no GOPATH set"
[13:40] <perrito666> natefinch: ahhhhhhhh
[13:40] <natefinch> What I want is a working version of this as my install script: yes, what I want is for my
[13:40] <natefinch> er http://pastebin.ubuntu.com/11264398/
[13:40] <natefinch> however the hell you make that work right
[13:41] <perrito666> natefinch: what is HOME?
[13:41] <perrito666> I mean, what exactly does it point to?
[13:41] <perrito666> that you just did there should work for your current shell and its forks iirc
[13:41] <natefinch> ok, I'll test it
[13:42] <perrito666> natefinch: but then again, also exporting it
[13:42] <perrito666> natefinch: assuming you have access to write the actual home of the user, you are tainting the machine
[13:42] <natefinch> exporting it definitely does not work
[13:42] <perrito666> natefinch: ok are you inside the hook tmux?
[13:43] <dooferlad> dimitern: *click*
[13:43] <perrito666> if so pastebin env
[13:43] <perrito666> natefinch: you can also GOPATH=/what/ever go get blah
[13:43] <natefinch> perrito666: hang on, let me rerun things with the new install script
[13:43] <natefinch> perrito666: that doesn't work either
[13:43] <natefinch> perrito666: I think it's forking processes or something that somehow are not getting the root process' env
[13:43] <perrito666> natefinch: then there definitely is something wrong there
[13:43] <natefinch> go get is, that is
[13:44] <perrito666> yes
[13:44] <perrito666> but forking a process should get the exported vars
[13:44] <perrito666> its like the only good reason to export
[13:44] <natefinch> haa well, $HOME is nothing, which is fantastic
[13:44] <natefinch> maybe that's the problem
[13:45] <perrito666> natefinch: it is appropriate, you are in a chrooted env most likely
[13:45] <dimitern> dooferlad, thanks! any reason not to check Ship it ?
[13:45] <perrito666> natefinch: you have superpowers though, you can use the system gopath
[13:46] <dooferlad> dimitern: mostly beause I don't have those powers. I haven't graduated, so I try not to.
[13:46] <dimitern> dooferlad, well, you could still express intent :)
[13:46] <dooferlad> dimitern: OK, will do next time!
[13:48] <natefinch> perrito666: ok, so I guess it was the fact that I was setting GOPATH to $HOME which was nothing... setting it to /home/ubuntu works fine
[13:49] <perrito666> natefinch: and makes your charm also ubuntu bound
[13:49] <TheMue> dimitern: reviewed
[13:49] <perrito666> natefinch: just use /go
[13:49] <natefinch> perrito666: k
[13:49] <perrito666> natefinch: or iirc /usr/shar/go?
[13:50] <perrito666> I never remember but there is a proper place for those things
[14:06] <dimitern> TheMue, thanks
[14:10] <TheMue> dimitern: only thought that it could make sense to test cloudinit.New() for all releases
[14:11] <dimitern> TheMue, it's tested in other places
[14:11] <TheMue> dimitern: ah, fine
[14:29] <katco> wwitzel3: ericsnow: natefinch
[14:29] <katco> sorry internet is being flaky the past few days
[14:30] <wwitzel3> katco: no worries
[14:30] <ericsnow> katco: np, we basically finished after you left
[14:30] <ericsnow> katco: I believe natefinch was going to ask about the blog :)
[14:39] <katco> i swear to god if this lady tells me one more time i have to power cycle my router i'm going to throw this phone.
[14:40] <perrito666> katco: but have you?
[14:40] <cherylj> ha, that's the worst.  Hang in there, katco :)
[14:41] <cherylj> I remember calling the "help desk" while I was at IBM and them not understanding when I told them I don' t have a start button because I'm using linux.
[14:41] <perrito666> the only good thing about my isp is that it is easy to know when there is a problem outside your immediate network, they just dont answer your call until its fixed
[14:42] <perrito666> cherylj: they are quite ok with that here, they tell you the command in linux to diagnose the network
[14:42] <perrito666> the people installing the connection are even cool with doing so in a computer running ubuntu, which is surprising
[14:42] <perrito666> they still require for you to have a computer with an ethernet por though, which is usually a problem around here
[14:44] <perrito666> katco: just mtr to google and see if you are dying before leaving the gw or after
[14:46] <katco> perrito666: that's exactly what i was doing
[14:47] <katco> perrito666: unfortunately, tier 1 lady said that there's no other way to troubleshoot the situation than to "bypass your router"
[14:48] <perrito666> katco: and by router they mean you r home one, not the one provided by them right?
[14:48] <katco> perrito666: yeah, not the modem
[14:49] <katco> perrito666: she didn't understand i can't just change my entire network to wait for the internet to go out again
[14:49]  * katco is just so frustrated
[14:49] <perrito666> katco: cant you just ssh into your router?
[14:50] <katco> perrito666: i can do lots of things, but it won't solve a problem in their network
[14:50] <perrito666> katco: lol
[14:50] <perrito666> if the problem its in their network it will solve itself eventually
[14:51] <katco> perrito666: yeah, usually i ride these out, but it's been dropping me pretty frequently the past few days
[14:51] <perrito666> my isp still hasnt called me to schedule the installation of my decent speed line because they cannot resolve their installer guy schedule (that is the level of inutility)
[14:51]  * TheMue passes katco a piece of chocolate to calm her nerves
[14:51] <perrito666> katco: cant you just ask for a rewiring/new modem?
[14:52] <perrito666> katco: just in case?
[14:52] <perrito666> i am not sure what is the policy there
[14:52] <katco> i mean... side by side, ping to modem, ping to 8.8.8.8. ping to modem fine, ping to 8.8.8.8 dropping. why is this not crystal clear?
[14:52] <natefinch> katco: comcast?
[14:52] <katco> natefinch: charter
[14:53] <natefinch> katco: ug, possibly worse
[14:53] <katco> natefinch: not sure if you guys have that up there
[14:53] <perrito666> I had a friend shot at the main telco distribution box because their policy only allowed to replace cabling if the cable had more than N meters missing (otherwise just patching) and only went to check the box if the box was completely dead
[14:53] <natefinch> katco: we have charter in town, actually... but since our property is on the town line of the next door town, which has fios, I just lied to verizon and said my address is in the next town (and put my billing address as my own town)
[14:53] <katco> lol
[14:54] <perrito666> so we got an insider tell us this (they where ignoring the rewiring request) so we basically chopped the cable by more than the required meters and shot the box (it is a place where said thing is not all that suspicious)
[14:54] <katco> ericsnow: natefinch: wwitzel3: was going to mention, i'm out for the next hour for a dr. appt. wwitzel3, if i'm late for our 1:1 that's why
[14:54] <katco> and if i drop out, now you know why >:|
[14:54] <wwitzel3> katco: ok, if I am late, I have no good excuse
[14:55] <katco> wwitzel3: lol
[14:55] <katco> k bbiab guys, ty for the moral support haha
[14:58] <natefinch> perrito666: nice work of vandalism
[14:58] <natefinch> perrito666: not that I disapprove :)
[14:58] <perrito666> natefinch: tx, the whole neigborhood was very happy
[14:58] <perrito666> they got new phone lines that dont go down on rainy days
[14:59] <natefinch> nice
[14:59] <perrito666> telcos are the worse, there are only 2 in the whole country one in the south and one in the north
[14:59] <perrito666> they are a very bad monopoly and usually cut so many corners that they are a circle
[14:59] <natefinch> perrito666: there's a bunch in the US, but we have government supported monopolies so that they don't ever have to compete in any particular town
[15:01] <perrito666> natefinch: I heard of people actually set their posts on fire so they got underground wiring
[15:01] <natefinch> perrito666: haha, wouldn't work here... they'd just install new posts
[15:01] <perrito666> natefinch: they dropped the posts 15 years ago
[15:02] <perrito666> they just decided not to replace them in some places until it was necessary
[15:02] <perrito666> to cut costs
[15:02] <perrito666> they have an explicit internal rule for service repairmen not to replace anything until is not working 80% of the time or more
[15:03] <Web> Big thanks to Juju team for all your work.  Without you my graduate project wouldn't have been such a success!
[15:03] <perrito666> Web: excelent, congrats on graduation? (will you do a blog post?)
[15:03] <cherylj> Web: I'm curious, what was your project?
[15:04] <perrito666> natefinch: in my birth town they even dropped the tech service, they send 2 people every month for a day and they just fix as much as they get to in that day and the rest just are postponed, there is a guy that works as an individual contractor for people to fix these things because no one expects the company to come anymore
[15:04] <natefinch> perrito666: that's pretty bad
[15:05] <cherylj> can I get a sanity check from someone on a review comment I received yesterday?  dave commented that there was a race in a particular test that I wrote, and I don't think there is:  http://reviews.vapour.ws/r/1740/
[15:05] <perrito666> natefinch: not for the individual contractor guy
[15:05] <natefinch> haha
[15:05] <Web> perrito666: I will be posting a detailed blog article soon on http://mastersproject.info.
[15:05] <cherylj> In the test, we synchronously call a function, APIWorkers which will call the reportClosedAPI function we're patching
[15:06] <cherylj> I just want to make sure I'm not missing something.
[15:06] <Web> cherylj: SaaS delivering questionnaire services with developer access.  Primarily a Node.js based application.  http://themindspot.com
[15:08] <cherylj> neato!  reading now
[15:08] <Web> Now I can start on cleaning it up and expanding the api to make native applications.
[15:08] <perrito666> cherylj: I am a bit out of context, what does reportClosedAPI does exactly
[15:09] <cherylj> it is just a function added to test that we actually close the api we opened in the case of failure.  In the non-test case, it is an empty function.  In the tests, we patch it to set some var to true to indicate that it was called.
[15:09] <Web> cherylj: Still alot of work to do to make it a viable service but the value and product was delivered on time and as expected with good software engineering practices.
[15:10] <cherylj> You can see how a similar pattern is used here:  https://github.com/juju/juju/blob/master/cmd/jujud/agent/machine_test.go#L858
[15:10] <cherylj> perrito666: ^^
[15:11] <cherylj> perrito666: but in the above case, they are creating a new goroutine and that's why they're using channels
[15:12] <perrito666> cherylj:  I am tracing the code
[15:12] <cherylj> thanks, perrito666
[15:12] <cherylj> Web: how was your experience using Juju?
[15:13] <perrito666> I am not sure here if deferreds run before or after returning from a function, natefinch ?
[15:13] <perrito666> I do believe they are blocking
[15:14] <perrito666> cherylj: anyway, given the logic there it think it would be mor go-ish and safer to use a channel and wait on it isntead of a bool
[15:14] <perrito666> more*
[15:14] <cherylj> thanks, perrito666!
[15:14] <Web> cherylj:  I have been enjoying Juju from the beginning.  I haven't been a charmer for awhile now but have always boasted Juju.  Thats why I knew it was perfect for creating my project proposal.
[15:15] <cherylj> Web: how did you first hear about it?
[15:17] <sinzui> katco, can you ask someone to triage bug 1457225. The case is somewhat extraordinary, I don't understand the severity or labour.
[15:17] <mup> Bug #1457225: Upgrading from 1.20.9 to 1.23.3 works, but error: runner.go:219 exited "machiner": machine-0 failed to set status started: cannot set status of machine "0": not found or not alive <cts> <sts-stack> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1457225>
[15:29] <natefinch> perrito666: deferred functions run before the function exits, but after return values are set.  They will be required to finished before the function exits
[15:30] <perrito666> natefinch: I assumed so which makes dave's comment wrong
[15:31] <perrito666> natefinch: but I believe that channel over flags is good anyway
[15:33] <alexisb> Web, glad to hear it! and congrats on a success graduate project!
[15:33] <natefinch> perrito666: http://play.golang.org/p/P2zB4t1Alf
[15:34] <perrito666> natefinch: and how is it handled in the low level?
[15:35] <perrito666> natefinch: is the defered a go routine with access to the namespace of the function or is  an appended func call or what?
[15:36] <Web> cherylj:  I don't even remember but I worked on a early version of node-app to implement some features m3 (Mark Mims) wanted.
[15:36] <natefinch> perrito666: it's not a goroutine.  I'm not sure exactly how it runs.  It does have a non-negligible performance impact, though not enough to care about unless it's in a really hot path
[15:36] <Web> alexisb: thank you very much.
[15:37] <perrito666> natefinch: uff, I assume its something like a try/catch
[15:38] <perrito666> natefinch: I am now tempted to read the go source for that
[15:40] <Web> Now I need to beautify and get some money to upgrade servers from t1.micro's if I want to make this a real service. :)
[15:50] <cjwatson> Hi, is there any way I can get juju's private mongod to not sit there spinning and calling select 100 times a second?  It's quite literally causing me to have to open a window to dissipate laptop heat any time I'm using juju
[15:50] <cjwatson> (jcastro sent me here from #juju)
[16:16] <katco> sinzui: ack
[16:16] <katco> ericsnow: wwitzel3: natefinch: back if you need anything
[16:17]  * natefinch has to spend a little time writing unit tests for his CI tests
[16:18] <katco> ...
[16:18]  * katco is actually not sure how she feels about that
[16:18] <natefinch> katco: https://code.launchpad.net/~natefinch/juju-ci-tools/logrot/+merge/259750
[16:20] <natefinch> katco: I know... on the one hand, it's nice to double check that the tests aren't malfunctioning, but on the other hand, it seems like a belt and suspenders and ... something else that holds up your pants... kind of approach
[16:20] <perrito666> natefinch: I use being fat for that, the belt/suspenders are just for aestethic reasons
[16:20] <katco> yeah... i honestly haven't ever thought about that enough to have an opinion, but the gut check says it seems excessive
[16:35] <marcoceppi> Web: congrats!
[16:41] <Web> marcoceppi: big thanks to you too!  Your always there when I've needed advice.
[16:44] <mup> Bug #1457566 was opened: lock timeout exceeded <deploy> <intermittent-failure> <juju-core:Incomplete> <juju-core 1.22:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1457566>
[16:44]  * perrito666 discovers that his mobile company uses the emergency broadcast alerts to send spam...
[16:45] <katco> i need a volunteer to look at bug 1457225
[16:45] <mup> Bug #1457225: Upgrading from 1.20.9 to 1.23.3 works, but error: runner.go:219 exited "machiner": machine-0 failed to set status started: cannot set status of machine "0": not found or not alive <cts> <sts-stack> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1457225>
[16:45] <katco> currently only triage needed
[16:46] <katco> cherylj: perrito666: dooferlad: voidspace: wwitzel3: ericsnow: natefinch-afk: TheMue: ^^
[16:50] <wwitzel3> katco: in a hangout with ericsnow, whit, and lazyPower
[16:50] <katco> wwitzel3: k lmk when you're ready
[16:55] <Web> Okay hadn't thought about applying to Canonical until today.  If you hear my name (Brandon L. Clark) in passing give me some praise.   And any advice?  :)
[17:24] <wwitzel3> katco: ping
[17:24] <katco> wwitzel3: pong
[18:02] <peterklipfel> Hi all, I'm wondering if anyone has any tips on where I can start with modifying the juju source. I've been using the project for ~1.5 years, but haven't contibuted anything. I'm not so good at go. The thing that I want to do is enable custom image usage on openstack on a per-machine basis. It's possible that this might be a big refactor due to (for example) colocating services on machines. Thoughts?
[18:06] <natefinch-afk> peterklipfel: using go will likely not be your biggest hurdle.  The language itself is quite small and easy to pick up if you know pretty much any other imperative language.  The codebase is quite large, which is the biggest hurdle for new developers.
[18:06] <natefinch-afk> nick natefinch
[18:07] <natefinch> peterklipfel: I woudl start here: https://github.com/juju/juju/blob/master/CONTRIBUTING.md
[18:08] <peterklipfel> natefinch: Right, I'm struggling to wrap my head around the codebase. I have the repository up and running, and have read through the contributing doc. I'm wondering if there's an architecture doc or something somewhere
[18:08] <natefinch> peterklipfel: adding the ability to use custom images is something we've been wanting to do for forever, but just haven't been able to put it up to the top of the priority list
[18:09] <natefinch> peterklipfel: I don't know if we really have a good architecture document.  There's some docs here: https://github.com/juju/juju/tree/master/doc   but a bunch are very old (note that some of them say "2 years ago"... which is a lifetime in the life of juju)
[18:10] <natefinch> peterklipfel: luckily... using custom images would just be something to be able to specify in the communication to the provider (openstack in this case), and the providers are pretty self-contained
[18:11] <peterklipfel> natefinch: I totally missed the "doc" folder. Thanks! Will be back later
[18:12] <natefinch> peterklipfel: probably you'd want to make image a constraint, as defined here: https://github.com/juju/juju/blob/master/constraints/constraints.go   and then figure out how to get the openstack provider to do the right thing with it inside its StartInstance method here: https://github.com/juju/juju/blob/master/provider/openstack/provider.go#L944
[18:14] <peterklipfel> natefinch: awesome. Thanks again
[19:03] <katco> natefinch: wrapping up last meeting
[19:03] <natefinch> katco: ok
[19:42] <bac> hey whit, thanks for the note on that juju-deployer bug.  any plans to get that moving? i think tvansteenburgh has commit rights now, which may speed things up.
[19:44] <whit> bac, yeah...
[19:44] <whit> bac, hazmat requested a test, and I've not had a chance to get back to it
[19:44] <bac> yeah, no one's favorite project.  :)
[19:45] <whit> it's a bit wierd because of the fact that it's dependent on git
[19:45] <whit> (testing that is)
[19:45] <whit> well, no single maintainer.
[19:46]  * whit has no ill will towards deployer
[19:53] <hazmat> whit: just set HOME=tmpdir()  and record identity .. you can setup a temp repo that way in the test without pulling down anything or checking in a repo
[19:54] <hazmat> alternatively just checkin a small git repo
[19:54] <hazmat> whit: the particular error that i saw was that it didn't respect JUJU_REPOSITORY env var
[19:55] <whit> hazmat, not sure about that one
[20:35] <mup> Bug #1457645 was opened:  warning: log line attempted over max size - leadership related <landscape> <juju-core:New> <https://launchpad.net/bugs/1457645>
[20:38] <mup> Bug #1457645 changed:  warning: log line attempted over max size - leadership related <landscape> <juju-core:New> <https://launchpad.net/bugs/1457645>
[20:44] <mup> Bug #1457645 was opened:  warning: log line attempted over max size - leadership related <landscape> <juju-core:New> <https://launchpad.net/bugs/1457645>
[20:46] <natefinch> what the heck is this even supposed to mean?  "missing namespace, config not prepared"
[20:47] <perrito666> the config is not prepared, you are missing a namespace
[20:47] <natefinch> thanks :/
[20:47] <perrito666> natefinch: where do you see that?
[20:47] <natefinch> when I do juju status on my local environment that is currently running
[20:48] <natefinch> I have a feeling something in the CI tests fubared my environment
[20:49] <natefinch> are we still supposed to have jenv files?
[20:49]  * natefinch notes he no longer has a local.jenv
[20:49] <perrito666> natefinch: the comment in the code does not make much sense either
[20:50] <natefinch> I think we are.  I think something in the CI tests blew away my jenv without destroying the CI tests
[20:50] <natefinch> yeah
[20:50] <natefinch> er sorry, without destroying the environment
[20:51] <thumper> natefinch: the namespace is added to the local config at environ prepare time
[20:52] <thumper> so if you aren't getting it, something has gone wrong
[20:52] <natefinch> thumper: I had no jenv for my local environment for some reason
[20:52] <thumper> natefinch: are you running with the jes flag?
[20:52] <natefinch> thumper: nope
[20:52]  * thumper thinks
[20:53] <thumper> natefinch: in the jes-cli branch, we now have 'cache.yaml' instead of .jenv files
[20:53] <thumper> but this won't be impacting you
[20:54] <natefinch> luckily, I have a script to blow away my local environment for just this kind of situation.  Notably it outputs "rm: cannot remove ‘/home/nate/.juju/environments/local.jenv’: No such file or directory"
[20:54] <natefinch> thumper: honestly, it was the error message more than anything that confused me.
[20:55] <thumper> hmm..
[20:55] <natefinch> thumper: totally not a useful error message for an end user, unless there's a juju prepare-config command I don't know about
[20:55] <thumper> agreed
[20:55] <thumper> some developer error messages should really be caught and translated into 'user speak'
[20:55] <natefinch> but hey, maybe it's different with jes now... might get lucky
[20:55] <natefinch> yep
[21:00] <natefinch> dinner time.  Back later folks.
[21:09] <ericsnow> could I get some eyes on patches revert changes that are breaking CI: http://reviews.vapour.ws/r/1757/ http://reviews.vapour.ws/r/1758/ http://reviews.vapour.ws/r/1759/
[21:14] <mwhudson> davecheney: i'm still amazed by the effectiveness of my golang-dev trolling about gc
[21:17] <davecheney> mwhudson: yeah
[21:17] <davecheney> it's been rather productive, we've now ruled out custom allocators
[21:17] <davecheney> and people are talking seriously about making Node and Proj smaller
[21:19] <mwhudson> i wonder if people have noticed how very slow the linker is
[21:19] <mwhudson> i could try some trolling in that direction
[21:53] <mwhudson> davecheney: you know that bit in cmd/go's build.go about link order for gccgo builds
[21:54] <mwhudson> davecheney: that we've fixed 1 million times
[21:54] <mwhudson> davecheney: if someone were to hypothetically rewrite it entirely, how would they know they haven't broken it?
[22:00] <ericsnow> katco: could you take a quick look at the other two as well (strictly reverts)
[22:19] <ericsnow> thanks davecheney
[22:27] <davecheney> mwhudson: try to build juju is a good teest
[22:29] <cherylj> davecheney: could you take a look at my changes for your review comments? http://reviews.vapour.ws/r/1740/
[22:40] <mwhudson> davecheney: ack
[22:53] <mwhudson> davecheney: any idea how long "go test -compiler gccgo github.com/juju/juju/..." will take?
[22:54] <mwhudson> 30 mins or so?
[22:55] <voidspace> mwhudson: hey michael
[22:55] <voidspace> mwhudson: o/
[22:55] <mwhudson> voidspace: hi!
[22:55] <voidspace> mwhudson: I'm up late doing (another) maas install
[22:55] <voidspace> mwhudson: how are things?
[22:56] <mwhudson> hm, pretty sure the go process isn't supposed to spin using 100% of cpu :(
[22:56] <voidspace> :-)
[22:57] <mwhudson> voidspace: ok, trying to actually make debian packages that contain go shared libraries now
[22:57] <voidspace> mwhudson: very cool
[22:57] <mwhudson> which involves a surprising and unfortunate amount of perl
[22:58] <voidspace> hehe, my commiserations
[22:58] <mwhudson> voidspace: how about you? are you sleeping with tcp illustrated under your pillow? :)
[22:59] <voidspace> mwhudson: I should be!
[22:59] <voidspace> gradually learning
[23:00] <voidspace> mostly learning the peculiarities of maas recently
[23:00] <voidspace> not sure that's such a transferable skill
[23:00] <voidspace> I like maas though
[23:00] <mwhudson> heh
[23:01] <mwhudson> i've wrangled it a bit in the past
[23:01] <voidspace> about to test bleeding edge apis around container IP address releasing
[23:01] <voidspace> which means installing bleeding edge maas
[23:02] <voidspace> which fails to configure when installed from the dailybuilds ppa
[23:02] <voidspace> so back to a vanilla install and then upgrading
[23:02] <voidspace> seeing as I can't work out how to manually run the configure script
[23:03] <voidspace> thankfully so far their upgrades have always done the right thing
[23:03] <voidspace> unlike ubuntu
[23:03] <voidspace> known issue - if you have an encrypted hard drive then upgrading to 14.10/15.04 means you can no longer enter the password
[23:03] <voidspace> fortunately you can still boot through recovery mode, which has a text password entry
[23:04] <voidspace> but given that there's no supported way of removing encryption I'm doing a recovery mode boot every time
[23:04] <mwhudson> ha oops
[23:04] <voidspace> :-)
[23:05] <mwhudson> i avoided that problem by having my laptop fall apart just before 15.04 was released
[23:05] <voidspace> that's one way I guess
[23:05] <voidspace> I haven't dared upgrade my laptop
[23:06] <mwhudson> although the gyrations required to mount my encrypted home dir from the drive after i'd pulled it from the laptop and stuck it in a caddy were... contorted
[23:06] <mwhudson> partly because i'd installed with lvm
[23:06] <voidspace> :-/
[23:06] <voidspace> computers
[23:06] <mwhudson> yeah, otoh usb3 + ssd = pretty fast restore
[23:07] <mwhudson> voidspace: about configuring maas, you should talk to rbasak
[23:07] <voidspace> mwhudson: thanks
[23:07] <mwhudson> his point is that setting up maas requires orchestration, i.e. juju
[23:07] <voidspace> mwhudson: if this doesn't work I will do
[23:07] <mwhudson> but there's a bootstrapping problem there :-)
[23:07] <voidspace> heh
[23:07] <mwhudson> he had some crazy scheme to use it regardless but i don't know what it was
[23:08] <mwhudson> i don't know if he would be of practical help
[23:09] <voidspace> installing maas is supposed to run configuration
[23:09] <voidspace> and if you're *supposed* to do it a different way they should document that
[23:09] <mwhudson> i'm pretty sure installing maas is supposed to work, yea :)
[23:10] <voidspace> it certainly always used to work
[23:28] <mwhudson> Broadcast message from systemd-journald@glamdring (Fri 2015-05-22 11:27:36 NZST):
[23:28] <mwhudson> [14085]: 2015-05-21 23:27:36 INFO juju.testing mgo.go:514 reset successfully reset admin password
[23:28] <mwhudson> wtf
[23:28] <voidspace> yeah, running the test suite on vivid spams systemd messages to the terminal
[23:28] <voidspace> ericsnow knows and cares
[23:30] <ericsnow> mwhudson: see #1456258
[23:30] <mup> Bug #1456258: systemd broadcast message spam during test run <papercut> <unit-tests> <juju-core:Triaged> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1456258>
[23:30] <mwhudson> ah cool
[23:31] <voidspace> right, I've failed to get MAAS working
[23:31] <voidspace> I've got as far as internal server error
[23:31] <voidspace> can't connect to cluster in the logs
[23:31] <voidspace> I'm going to bed
[23:31] <voidspace> g'night all
[23:35] <mwhudson> i think running the tests with gccgo ran my machine to close to out of memory