[00:00] <mwhudson> davecheney: can you run lspci?
[00:02] <davecheney> not at the moment
[00:03] <davecheney> the machine went away
[00:03] <davecheney> i suspect brad is playing kernel games
[00:07] <mwhudson> also possible
[00:48] <menn0> thumper or wallyworld: i'm going to ask niemeyer to look at this before merging but if you could take an initial look: http://reviews.vapour.ws/r/1705/
[00:48] <menn0> this is the "hard part" of the fix for keeping the txns collection at a sane size
[00:49] <wallyworld> menn0: i really hope this gets into mgo were it belongs
[00:54] <menn0> wallyworld: agreed. this is just to get something into juju sooner.
[01:21] <davecheney> thumper: menn0 https://go-review.googlesource.com/#/c/10135/2
[01:21] <davecheney> fix for websocket issue
[01:21] <davecheney> going to try to get it upstreamed ASAP
[01:21] <davecheney> or otherwise I will deliver it on a branch
[01:41] <thumper> davecheney: thanks
[01:54] <mwhudson> luckily brad seems to be an insomniac workaholic :)
[01:54] <mwhudson> well, i guess it's not that late for him, it is sunday though
[01:59] <davecheney> his loss is our gain
[01:59] <davecheney> ok, patch comitted
[02:09] <davecheney> thumper: menn0 https://github.com/juju/juju/pull/2344
[02:33] <cherylj> btw, davecheney, there is an actual file handle leak for bug 1420057
[02:33] <mup> Bug #1420057: agents see "too many open files" errors after many failed API attempts <juju-core:Triaged by dave-cheney> <juju-core 1.22:In Progress by dave-cheney> <juju-core 1.23:In Progress by dave-cheney> <juju-core 1.24:In Progress by dave-cheney> <https://launchpad.net/bugs/1420057>
[02:33] <cherylj> I saw it after testing the websocket changes
[02:33] <cherylj> I just updated the bug with info
[02:33] <cherylj> testing a fix now
[02:33] <davecheney> cherylj: ok
[02:34] <davecheney> so, https://github.com/juju/juju/pull/2344
[02:34] <davecheney> i'm patching that back all the way back to 1.22
[02:35] <menn0> thumper: 1:1?
[02:35] <thumper> menn0: there shortly
[02:35] <menn0> thumper: np
[02:36] <menn0> cherylj: nice job finding another leak
[02:36] <cherylj> davecheney: sounds good.  I think the combination of that, plus this fix I'm testing is required
[02:36] <cherylj> menn0: thanks :)
[02:36] <davecheney> cherylj: ok, i don't know how to track backporting the websocket dependency
[02:36] <davecheney> change
[02:36] <davecheney> so i'll just pretend like someone else does
[02:37] <davecheney> thumper: ... value *errors.Err = &errors.Err{message:"", cause:(*net.OpError)(0xc21054c440), previous:(*errors.Err)(0xc2106a26e0), file:"github.com/juju/juju/state/open.go", line:69} ("cannot create database index: local error: bad record MAC")
[02:37] <davecheney> ... error stack: local error: bad record MAC
[02:37] <davecheney> annnd there goes another 20 minutes
[02:37]  * thumper sighs
[03:23] <davecheney> thumper: merge to trunk successful
[03:23] <davecheney> 1.23 and 1.24 branches incoming
[03:23] <davecheney> 1.22 unaffected, doesn't use x/net/websocket
[03:26] <davecheney> thumper: ok
[03:26] <davecheney> 1.22 will still be using code.google.com
[03:26] <davecheney> do I need to update all the deps in 1.22 to use the github version of the websocket library ?
[03:26] <davecheney> thumper: ?
[03:27] <thumper> oh...
[03:27] <thumper> um...
[03:27] <thumper> ideally
[03:27] <thumper> sed?
[03:28] <davecheney> it's not a hard job
[03:28] <davecheney> just a slightly large one
[03:29] <davecheney> i'll do it afte rlunch
[03:36] <thumper> kk
[03:36] <thumper> ta
[03:56]  * thumper afk to collect daughter from school
[03:56] <thumper> bbs
[05:22] <davecheney> godeps: cannot update "/var/lib/jenkins/workspace/github-merge-juju/tmp.BEr8lKzge2/RELEASE/src/bitbucket.org/kardianos/service": cannot create repo: cannot find project root: Get https://api.bitbucket.org/1.0/repositories/kardianos/service: EOF
[05:22] <davecheney> great
[05:22] <davecheney> just peachy
[05:23] <davecheney> can't build 1.24 anymore
[05:23] <davecheney> yay reproducible builds
[05:33] <davecheney> any on call reviewers in the channel ? http://reviews.vapour.ws/r/1711/
[07:19] <davecheney> any on call reviewers in the channel ? http://reviews.vapour.ws/r/1711/
[07:44] <TheMue> morning o/
[07:46] <dimitern> morning TheMue
[08:02] <dimitern> TheMue, sorry, I'll be 10m late for our 1:1
[08:02] <TheMue> ok
[08:11] <dimitern> TheMue, I'm in the hangout
[08:11] <TheMue> ok, coming
[08:17] <davecheney> mwhudson: scaleway servers don't support neon
[08:17] <davecheney> how the F did they manage that !?!
[09:56] <mwhudson> davecheney: ah yeah was going to paste https://twitter.com/edouardb_/status/600211988552224768
[09:56] <mwhudson> well, less transistors doing simd means more cpus on a die or something i guess
[09:57] <mwhudson> seems an odd choice
[10:03] <mwhudson> alternatively marvell had a bucket of armada 370s they wanted to get rid of
[13:02] <sinzui> mgz, did you look into the maas 1.7 failures?
[13:04] <sinzui> looks like it is thoroughly dead.
[13:24] <mgz> sinzui: I saw them, and wimped out
[13:25] <mgz> sinzui: if you're going to do some maas resurrection now I'd like to tag along
[13:25] <sinzui> mgz: Me. The vms are paused and the nodes are gone. I don't think jog dismantled the maas, but something has
[13:26] <sinzui> mgz: I want to consult with jog first. I think we need to unpause 1.7, probably restart it too, then use the utility script to make 15 new nodes
[13:27] <mgz> hm, I sohuld have disabled the jobs on jenkins, didn't think of that
[13:55] <sinzui> mgz, can you review this to unblock 1.22.4 testing http://reviews.vapour.ws/r/1713/
[13:55] <mgz> sinzui: shipit
[14:03] <katco> ericsnow: stand up
[14:28]  * katco just noticed that out of context, her previous comment can be regarded as a weird request that ericsnow stop sitting.
[14:29] <ericsnow> :)
[14:30] <mgz> katco: having a space in standup makes it seem more like a command :)
[14:30] <perrito666> mgz: who says it isnt?
[14:30] <katco> mgz: hehe yeah. maybe i should make it a proper noun "Standup"
[14:31] <perrito666> katco: you could upgrade with a : now!
[14:32] <katco> perrito666: that would just be rude :|
[14:32] <perrito666> well it works for shutdown
[14:32] <perrito666> why would it not work for stand up :p
[14:32] <ericsnow> cherylj: the solution for systemd/cloudinit that you wrote up in the bug sounds correct
[14:32] <katco> lol, for shutdown i'm commanding a machine
[14:32] <cherylj> cool, thanks ericsnow
[14:34] <ericsnow> cherylj: it may be worth double-checking with smoser about it
[14:34] <ericsnow> cherylj: I expect he wrote the systemd configs for cloudinit
[14:35] <cherylj> ericsnow: thanks, will do
[14:42] <ericsnow> cherylj: let me know when you have a patch and I'll review it
[14:42] <ericsnow> cherylj: or ping me if you want any other feedback
[14:42] <cherylj> ericsnow: thanks.  I'll probably have it ready this afternoon.  I'm working on a different bug this morning.
[14:42] <ericsnow> cherylj: np
[15:04] <voidspace> ericsnow: every time I do a full test run I get systemd broadcast messages spammed to every terminal
[15:04] <voidspace> ericsnow: and I blame you...
[15:04] <voidspace> haven't tracked down which test it is yet
[15:05] <ericsnow> voidspace: I accept it :/
[15:05] <voidspace> hehe
[15:05] <ericsnow> voidspace: what are the messages?
[15:06] <ericsnow> voidspace: you're running vivid?
[15:06] <voidspace> ericsnow: yes
[15:06] <ericsnow> voidspace: (by which I mean systemd)
[15:06] <voidspace> ericsnow: debug level log messages
[15:06] <voidspace> np
[15:06] <voidspace> * lucap_ (l
[15:06] <voidspace> gah
[15:07] <voidspace> Broadcast message from systemd-journald@UbuntuBox (Mon 2015-05-18 16:04:10 BST):
[15:07] <voidspace> [23762]: 2015-05-18 15:04:10 DEBUG juju.apiserver apiserver.go:273 <- [7] machine-1 {"RequestId":6,"Type":"NotifyWatcher","Id":"2","Request":"Stop","Params":"'params redacted'"}
[15:07] <voidspace> etc...
[15:07] <voidspace> to *every* damn terminal
[15:07] <voidspace> including vim
[15:07] <voidspace> :-)
[15:07] <ericsnow> voidspace: yuck
[15:08] <ericsnow> voidspace: hmm, this is probably going to require more than a minute to track down...
[15:08] <ericsnow> voidspace: would you mind opening a bug on this (against 1.23 and up)
[15:09] <voidspace> ericsnow: ok
[15:09] <voidspace> thanks
[15:09] <voidspace> ericsnow: I was only complaining...
[15:09] <ericsnow> voidspace: :)
[15:10] <ericsnow> voidspace: I'm sure it will bug everyone at some point and it *could* imply some other issue
[15:10] <voidspace> :)
[15:11] <ericsnow> wwitzel3: I just realized I never applied your rb_webhooks patch to our install :(
[15:12] <wwitzel3> ericsnow: do it :)
[15:12] <ericsnow> wwitzel3: I've done so now (PRs should now be links)
[15:12] <wwitzel3> ericsnow: thanks :)
[15:12] <ericsnow> wwitzel3: unfortunately it only helps with new PRs
[15:13] <wwitzel3> ericsnow: yeah, I briefly looked at what to do for historical ones and decided it wasn't worth it
[15:13] <ericsnow> wwitzel3: yeah that shouldn't matter within a few weeks
[15:13] <ericsnow> wwitzel3: just wish I'd applied it when I merged your PR :)
[15:18] <voidspace> http://www.cattlerap.com/
[15:19] <jcastro> mgz: anything new wrt. dreamcompute?
[15:22] <perrito666> voidspace: that is actually quite catchy
[15:22] <voidspace> perrito666: :-)
[15:22] <voidspace> it's ridiculous
[15:22] <voidspace> wwitzel3: afternoon
[15:22] <perrito666> voidspace: its not really unpleasant as background noise
[15:22] <wwitzel3> voidspace: hey :)
[15:22] <voidspace> o/
[15:22] <mgz> jcastro: you saw my reply right?
[15:23] <perrito666> I should try with spanish auctions but since we use less words it might not be so rap like
[15:27] <voidspace> ericsnow: https://bugs.launchpad.net/juju-core/+bug/1456258
[15:27] <mup> Bug #1456258: systemd broadcast message spam during test run <papercut> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1456258>
[15:27] <ericsnow> voidspace: thanks
[15:28] <voidspace> ericsnow: couldn't see how to mark it as affecting 1.23 without targetting to a milestone
[15:28] <voidspace> which seemed innapropriate
[15:29] <ericsnow> voidspace: yep
[15:29] <ericsnow> voidspace: np
[15:29] <ericsnow> voidspace: you only get the spam when running the test suite, right?
[15:30] <voidspace> ericsnow: yeah, so far
[15:30] <voidspace> ...
[15:30] <voidspace> ericsnow: I haven't narrowed down which test it is I'm afraid
[15:30] <ericsnow> voidspace: no worries
[15:31] <voidspace> ericsnow: the messages appear (always) before the output line for cmd/juju
[15:32] <voidspace> ericsnow: but running those tests alone doesn't produce it
[15:39] <mup> Bug #1456258 was opened: systemd broadcast message spam during test run <papercut> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1456258>
[15:50] <mgz> jcastro: was hoping to get some juju hacking time on sunday, but have now filed bug 1456265 at least to track it
[15:50] <mup> Bug #1456265: Openstack provider should with without object-store <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1456265>
[15:58]  * natefinch just hit esc :wq from sublime :/
[15:59] <perrito666> and that doesnt work?
[15:59] <perrito666> I am surprised
[15:59] <perrito666> :p
[16:00] <natefinch> heh
[16:00] <natefinch> You could probably configure it to work
[16:08] <perrito666> I believe there is a vim mode for almost everything
[16:15] <mup> Bug #1456265 was opened: Openstack provider should with without object-store <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1456265>
[17:06] <natefinch> heh, just accidentally proved that the CI test I wrote fails on an unfixed version of Juju
[17:07] <natefinch> "Why the hell isn't this working? ..... oh, this is an old version of 1.24, duh"
[17:21] <natefinch> mgz, sinzui: I have a test charm that I need to call actions on... am I correct in thinking the current jujupy doesn't have support for calling actions?
[17:22] <sinzui> natefinch, no yet.
[17:23] <sinzui> natefinch, We certainly intend to add actions to you dummy charms, and jujupy needs to grow support
[17:23] <natefinch> sinzui: cool, well, maybe I can help out, since I need it right no
[17:23] <natefinch> now
[17:23] <sinzui> natefinch, fab, we love contributions
[18:25] <voidspace> right, EOD
[18:25] <voidspace> g'night all
[18:25] <mup> Bug #1362324 changed: Unit tests dying on PPC64el on 1.20.6 <intermittent-failure> <ppc64el> <juju-core:Invalid> <https://launchpad.net/bugs/1362324>
[18:25] <mup> Bug #1393986 changed: TestStartInstanceWithUnknownAZError nil deref panic <intermittent-failure> <test-failure> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1393986>
[18:49] <perrito666> rick_h_: can I ask you the "gvim question of the month" ?
[18:58] <rick_h_> perrito666: sure thing
[18:59] <perrito666> do know to what settings do the gui components other than the editor obey? (especially the tabs)
[19:00] <cherylj> hey ericsnow, turns out that there's an option in cloud-config for cloud init to halt the system when it's done:  https://cloudinit.readthedocs.org/en/latest/topics/examples.html#reboot-poweroff-when-finished
[19:00] <ericsnow> cherylj: perfect
[19:00] <perrito666> rick_h_: I have  some visual effort to determine the current tab
[19:00] <rick_h_> perrito666: parsing
[19:02] <rick_h_> perrito666: so do you mean like the menu bar and such?
[19:02] <perrito666> yes, I am not sure if it is gtk, because it looks different than the rest of my system
[19:03] <rick_h_> perrito666: oh, yea, there's vim-gtk the package that uses gtk
[19:03] <perrito666> and gvim tabs is a very polluted search
[19:03] <rick_h_> perrito666: maybe check lxappearance if you're not finding it listening
[19:04] <rick_h_> as there's gtk and then there's the rest of unity stuff? /me doesn't have any decorations so can't say for sure tbh
[19:04] <perrito666> rick_h_: tx, ill hack a bit the gtk theme to see if I can get the active tab to be more evident
[19:04] <rick_h_> perrito666: stop using tabs :P
[19:04] <rick_h_> perrito666: I fought against vim forever saying I couldn't use it until it had tabs. Then it got tabs and now I realize if I'm using tabs I messed up
[19:05] <rick_h_> perrito666: but say that tongue in cheek.
[19:05] <perrito666> lol, I use tabs to create a visual path of the code, very useful when you have 6 or 7 lovely levels of indirection
[19:06] <perrito666> console vim tabs are easy to style but gtk ones seem a bit harder
[19:19] <natefinch> sinzui: I'm a little lost with the CI tests... are the subclasses of TestCase the actual CI tests... or are those just unit tests for the test code itself?  If the latter, how does one construct a CI test?
[19:19] <natefinch> sinzui: (as always, if there's documentation, feel free to just send me to that)
[19:20] <sinzui> natefinch, test_*.py are tests for the test harnesses. the *.py scripts setup tests
[19:21] <sinzui> natefinch, for ever feature added jujupy.py, we expect to see it exercised in test_jujupy.py
[19:21] <natefinch> sinzui: ok
[19:25] <natefinch> sinzui: I'm still not sure I understand, actually.  When you say "tests for the test harness" does that mean "tests that test the testing code" or "tests that show up in jenkins as failed tests indicating juju bugs"?
[19:26] <sinzui> natefinch, none of the scripts in juju-ci-tools are specific tests for anything
[19:26] <sinzui> natefinch, juju-ci-tools containts the libraries and scripts to create juju tests in Jenkins.
[19:27] <natefinch> sinzui: ok, good to know.  So I would add the action-running functions there.....    how does one "create juju tests in Jenkins"?
[19:30] <sinzui> natefinch, working examples include deploy_stack.py, quickstart_deploy, and assess_recovery.py.
[19:31] <natefinch> sinzui: I thought you said none of those tests were specific tests for anything?
[19:31] <sinzui> natefinch, We wrote those scripts to work on our machines, using cloud-city, then setup in jenkins that pass the arguments to test a version of juju in a specific environment
[19:32] <sinzui> natefinch, they don't because without a version of juju and environment written in a jenkins job, it is generic
[19:33] <sinzui> natefinch, in http://reports.vapour.ws/releases/2657/job/aws-deploy-precise-amd64/attempt/2649, the actual command to for that test is
[19:33] <sinzui> timeout -s INT 30m /mnt/jenkinshome/juju-ci-tools/deploy_job.py --new-juju-bin ./extracted-bin/usr/lib/juju-1.25-alpha1/bin --series precise test-release-aws /var/lib/jenkins/jobs/aws-deploy-precise-amd64/workspace/artifacts aws-deploy-precise-amd64
[19:52] <mup> Bug #1456315 was opened: Received disconnect from ...: 2: Too many authentication failures for ubuntu <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1456315>
[20:33] <natefinch> my #1 complaint about python:  I have no f'ing clue what any particular function will return.
[20:35] <perrito666> natefinch: have faith
[20:35] <perrito666> it is also my number one complaint aboubt declaring things with := instead of explicit declarations in go, and you dont see me complaining about :p
[20:36] <perrito666> natefinch: just assume it will return something whith the api you need, and it will almost always be the case
[20:36] <natefinch> perrito666: yes but I mean, even when *looking at the source* I can't tell what a python function returns
[20:37] <natefinch> at least in Go the types returned are declared in the function signature
[20:37] <perrito666> natefinch: well if the code is properly written you can see what the returned object looks like
[20:38] <perrito666> not knowing the type "is a feature"
[20:38] <perrito666> but I always said that python could benefit from interfaces
[20:38] <perrito666> or some sort of contract
[20:39] <perrito666> as a side effect, it makes you choose more carefully who you code with :p
[20:51] <natefinch> sinzui: is the way that we make a test fail is to have it raise an exception, or is there some other way to signal failure?
[20:52] <sinzui> natefinch, jenkins only uses exit codes :(. 0 as pass and anything else is fail. There is no concept of skipped or error in setup.
[20:53] <natefinch> sinzui: ok.  Looks like the standard setup is to just wrap everything in a try/except and exit(1) if an exception is caught, which works well enough for my purposes.
[20:54] <sinzui> natefinch, yep, because python will set an exit code. We also like to read the error to diagnose why it failed
[21:21] <ericsnow> wwitzel3: PTAL: http://reviews.vapour.ws/r/1716/
[21:23] <davecheney> thumper: nope, still busted, https://github.com/golang/go/issues/10844#issuecomment-103086849
[21:23] <thumper> davecheney: heh
[21:26] <davecheney> to everyone to gophercon
[21:26] <davecheney> have you used the hotel discount codes on the website ?
[21:27] <cherylj> davecheney: I had the travel provider use the code when she booked the hotel
[21:28] <davecheney> thanks!
[21:37] <mup> Bug #1456343 was opened: APIServer Run method doesn't validates if Machines, Services or Units are present on the request. <juju-core:In Progress by niedbalski> <https://launchpad.net/bugs/1456343>
[21:45] <wwitzel3> ericsnow: looking
[21:45] <ericsnow> wwitzel3: ta
[21:49] <mup> Bug #1456343 changed: APIServer Run method doesn't validates if Machines, Services or Units are present on the request. <juju-core:In Progress by niedbalski> <https://launchpad.net/bugs/1456343>
[21:54] <davecheney> and for my next magic trick, I will spend all day git bisecting which revision of the gc broke juju
[21:54]  * davecheney pulls rabbit from hat
[21:55] <mup> Bug #1456343 was opened: APIServer Run method doesn't validates if Machines, Services or Units are present on the request. <juju-core:In Progress by niedbalski> <https://launchpad.net/bugs/1456343>
[22:20] <wwitzel3> ericsnow: ok, actually looking now, sorry, was emailing
[22:20] <ericsnow> wwitzel3: np
[22:21] <wwitzel3> ericsnow: ptal at my email when you can :)
[22:21] <ericsnow> wwitzel3: already started :)
[22:42] <ericsnow> wwitzel3: I've addressed your review comments on 1716
[23:45] <axw> wallyworld: just reading your email about bootstrap. am I crazy, or did you not actually propose to change the default behaviour of auto-upgrading in the end?
[23:45] <axw> wallyworld: "bootstrap with no version specified" sounds like what we do now?
[23:45] <axw> except without an agent restart
[23:47] <wallyworld> axw: yeah, that's what we do now. i was advocating keeping that for compatability and introducing a new option for repeatability
[23:47] <wallyworld> axw: but the current option would no longer reboot agents
[23:47] <axw> wallyworld: which is basically just moving agent-version from environments.yaml to a CLI option
[23:47] <axw> ok
[23:48] <axw> sounds fine, I just thought there was going to be a bigger change
[23:48] <wallyworld> yes, - so it's a cleaner approach, and will avoid agent restarts
[23:48] <wallyworld> i tried to keep it as minimal as possible in terms of change
[23:48] <wallyworld> but getting us to a better place
[23:49] <axw> wallyworld: how do you prevent restart? don't start until it's got to the target version?
[23:49] <axw> I mean, don't accept conns
[23:49] <wallyworld> axw: not 100% clear yet - need to work through implementation
[23:49] <axw> okey dokey
[23:50] <wallyworld> but could be something like that
[23:50] <wallyworld> axw: i was going to leave that up to anastasiamac to figure out :-)
[23:50] <axw> ah :)
[23:50] <anastasiamac> hmm :... thanks wallyworld :D... i think :))
[23:51] <axw> bbl