[00:16] <bigjools> $ juju status
[00:16] <bigjools> ERROR state/api: websocket.Dial wss://10.55.60.209:17070/: EOF
[00:16] <bigjools> what does that mean?
[00:16] <bigjools> everything is up AFAICS
[00:28] <bigjools> well, here we go:
[00:28] <bigjools> -rw-r----- 1 syslog adm    25G May 13 06:38 all-machines.log
[00:28] <bigjools> -rw-r--r-- 1 root   root   23G May 15 00:28 machine-0.log
[00:33] <bigjools> Filed https://bugs.launchpad.net/juju-core/+bug/1319608
[00:33] <_mup_> Bug #1319608: Poor error message when "status" fails <juju-core:New> <https://launchpad.net/bugs/1319608>
[00:33] <bigjools> and https://bugs.launchpad.net/juju-core/+bug/1319607
[00:33] <_mup_> Bug #1319607: Logs are not rotated <juju-core:New> <https://launchpad.net/bugs/1319607>
[00:48] <menn0> well I just learned something. If you put "NOT LGTM" in a review, Rietveld counts that as disapproval.
[00:55] <davecheney> yup
[01:08] <bigjools> axw: the dupe detector never works in LP does it? :)
[01:08] <bigjools> you'd think my keywords would have matched that one you duped it to
[01:11] <axw> bigjools: took me a few searches too
[01:11] <axw> bigjools: only "logrotate" came up with it
[01:11] <bigjools> urgh
[01:11] <bigjools> I must admit I was surprised when I didn't see a dupe
[01:12] <bigjools> hey while I am here, what's the approved way to upgrade a bootstrap node? I have one on precise that I want on trusty.
[01:12] <bigjools> just a regular dist upgrade?
[01:13] <axw> I'm not sure that we have an approved method... I actually don't know what happens if you change series underneath juju
[01:17] <axw> wallyworld_: I'm ready whenever you want to have a standup
[01:18] <wallyworld_> sure
[01:26] <bigjools> axw: it's an interesting question in the context of a distro going out of support
[01:29] <axw> bigjools: agreed, I just don't know the answer ;)
[01:37] <thumper> axw, wallyworld_: small review? https://codereview.appspot.com/93410043/
[01:37] <wallyworld_> ok
[01:38] <axw> funny man
[01:38] <wallyworld_> wtf
[01:38] <wallyworld_> small
[01:49] <axw> thumper: reviewed
[01:49] <thumper> thanks
[01:49] <thumper> I was trying to be funny 8-)
[01:49] <axw> wallyworld_: I think lxc-use-clone made it into 1.18.3 didn't it?
[01:49] <thumper> but didn't notice the responses until my client pinged me
[01:50] <axw> wallyworld_: so I think we should technically handle upgrade/deprecation warning
[01:50] <axw> but I wonder if it's really worthwhile, given how long it's been out
[01:50] <wallyworld_> axw: ah, yeah. for some reason i had convinced myself it hadn't
[01:51] <wallyworld_> sadly if it's in 1.18.3 i think we need to
[01:51] <thumper> axw: I was trying to keep the diff small
[01:51] <thumper> you might not think that...
[01:51] <thumper> but I did
[01:51] <axw> :)
[01:52] <thumper> I'll review the use of coreerrors
[01:52] <axw> it was mostly trivial anyway
[01:52] <axw> wallyworld_: sorry about that
[01:52] <wallyworld_> no need to say sorry
[01:52] <axw> wallyworld_: wish I had remembered there was an existing config earlier
[01:52] <thumper> axw: only 33 matches in 14 files
[01:53] <wallyworld_> i should have picked it up in review
[01:53] <wallyworld_> but we were rushed to try and get something to them
[02:03] <axw> sinzui: are you awake?
[02:04] <axw> sinzui: actually never mind... question is for someone else
[02:04] <axw> wallyworld_: do you know if the bot uses juju-mongodb?
[02:04] <axw> or just mongodb-server
[02:05] <wallyworld_> axw: not sure but i can check, just otp at the moment
[02:05] <axw> sure
[02:08] <sinzui> aws It was using mongodb-server
[02:08] <sinzui> jam1 forced it to install
[02:08] <sinzui> axw, ^ sorry It is a bit late
[02:09] <axw> sinzui: thanks
[02:09] <sinzui> axw, and CI installs both mongos for the trusty test as of last week
[02:09] <axw> ok cool
[02:24] <waigani> axw: reading through the code. does azure call a vm a "role"?
[02:25] <axw> waigani: yes that is right
[02:25] <axw> waigani: there is a doc on azure in dthe docs directory
[02:25] <waigani> okay, I should probably read that
[02:25] <waigani> axw: and the api lib is called gwacl. Both very misleading
[02:26] <axw> waigani: roles can be things other than VMs, but for our purposes they are the same
[02:27] <waigani> axw: just within azure right?
[02:27] <axw> yes, azure roles
[02:27] <waigani> axw: we might be introducing authorisation roles for users
[02:28] <axw> ah, yeah, totally different type of role :)
[02:28] <waigani> yeah!
[02:30] <thumper> gah... dumb gobot
[02:30]  * thumper tries to remember how to get there
[02:31] <wallyworld_> thumper: 10.55.61.118
[02:31] <thumper> wallyworld_: I have an alias called "gobot"
[02:31] <thumper> wallyworld_: that does the ssh for me so I don't have to think
[04:07] <thumper> \o/ r2731
[04:07]  * thumper does a little dance
[04:07]  * thumper loses energy and goes back to writing planning documents
[04:31] <thumper> davecheney, waigani, menn0: iteration one email sent out, I'm still working on the work item breakdown
[04:40] <waigani> thumper, davecheney, menn0: first pass over codebase's current use of identity: https://docs.google.com/a/canonical.com/document/d/1t8i0uHuHM3zgPC8QF0_v_K3SB6syXM32IxTZGIJd_f0/edit#
[04:49] <davecheney> thumper: ta
[05:26] <axw> wallyworld_: heading out shortly, will review your test suite branch when I get back
[05:26] <wallyworld_> ok, ta
[05:26] <wallyworld_> finally got it all to work
[06:05] <menn0> can anyone help me with a bzr newbie question?
[06:25] <jam> fwereade: when you're around, I would like to run something by you quickly
[07:11] <axw> jam: is gobot running in lcy01 or lcy02? and do you know the constraints of the machine?
[07:11] <axw> jam: I can't reproduce the peergrouper error locally, but it's happening pretty frequently on the bot now...
[07:12] <jam> axw: I believe we've bounced back and forth, but right now we're on lcy01with a dual-core 4GB machine
[07:12] <jam> axw: it is also running precise, if that matters
[07:12] <axw> jam: cool, thanks
[07:41] <TheMue> morning
[07:41] <TheMue> jam: just answered your mail, free for a hangout now
[07:42] <jam> TheMue: morning. I'm jut finishing up some stuff, can we chat in about 1 hr?
[07:42] <TheMue> jam: yep, I’m ready when you are
[07:43] <TheMue> jam: hmm, just wrote you that I’ve read your mail and answered it directly after my „morning“, but cannot see it here *stunning* seems I accidently cancelled the sending :(
[07:44] <TheMue> oh,done a refresh now, it’s there. strange.
[07:44] <jam> I got it
[07:45] <TheMue> jam: yeah, I see it now. looks like a display problem with my client.
[08:34] <voidspace> morning all
[08:40] <TheMue> voidspace: heya
[08:52] <axw> jam: would you mind importing my lp key into the bot? I'd like to have a look around to see if there's something different to the instance I created; I still can't reproduce the error even in lcy01 with the same constraints
[08:53] <jam> axw: axwalk?
[08:53] <axw> jam: yup
[08:54] <jam> axw: done 10.55.61.118 is the IP
[08:54] <axw> thanks
[08:55] <axw> jam: sorry, what user?
[08:56] <axw> system login
[08:58] <axw> nm, realised it's ubuntu
[09:03] <axw> fwereade: never realised comprise could be used like that; I always use compose in that case
[09:04] <fwereade> axw, it's a funny word, part of me always worries that I'm using it the wrong way round
[09:04] <axw> fwereade: SIGABRT tells the machine agent to exit with ErrTerminateAgent, which is what causes a cleanup
[09:05] <axw> fwereade: it's for the manual provider, but I don't think we actually need it anymore
[09:05] <fwereade> axw, a cleanup on the state server though? or just a local cleanup of the upstart conf etc?
[09:05] <axw> fwereade: the Destroy method for manual does all the things now anyway, in case the machine agent didn't get set up correctly
[09:05] <axw> umm
[09:05] <axw> removes the upstart conf, and deletes the data-dir
[09:06] <fwereade> axw, yeah, thought so
[09:06] <fwereade> axw, I am definitely wondering if we still want it
[09:06] <fwereade> axw, it's a bit of a drastic kill-switch in general I think
[09:07] <axw> fwereade: the main benefit is that the server may know about things that the client does not
[09:07] <axw> fwereade: e.g. if the server is a version ahead of the client
[09:10] <jam> axw: you ssh in as ubuntu, the test suite runs as user "tarmac"
[09:11] <axw> jam: thanks. I was hoping not to have to run them manually, but I can't see any obvious discrepancies. what's the protocol for locking the bot so I can run tests manually?
[09:11] <jam> axw: flock -n /home/tarmac/tarmack.lock sleep 3600
[09:11] <jam> is what I run in screen
[09:12] <jam> (screen -xRR as the Ubuntu user will get you some interesting shells
[09:12] <axw> thanks
[09:12] <axw> argh! ascii goatse
[09:13] <jam> axw: I said they were interesting, I didn't specify SFW :)
[09:13] <axw> ;)
[09:13] <jam> I do think ascii goatse would lose some of its oomph
[09:32] <axw> fwereade: that shouldEnableHA code is intended to be temporary; certainly if/when the local provider is changed to have an external provider agent, we could enable it for all providers
[09:32] <axw> fwereade: it's only disabled at all right now because there's a bug in the replicaset initiation code (or mongo?)
[09:32] <axw> theoretically it should be fine to initiate with a single member
[09:35] <jam> axw: so wallyworld_ had tests fail with --replicaSet passed, but neither thumper nor I had the test suite fail with it.
[09:36] <axw> jam: yeah. I think there may have been failures on the bot too? or CI? I forget
[09:36] <jam> I believe CI said that local was failing for them
[09:36] <axw> so AFAIK we don't do anything special for local, so really it's a bit of a hack to disable it for local
[09:36] <axw> we're probably just papering over general brokenness
[09:41] <jam> axw: yeah, my concern is that it really is something that would be failing ,we are just *noticing* in the CI local tests.
[09:41] <jam> axw: there *is* a reason to disable HA for local, because only machine-0 can actually do provisioning
[09:41] <axw> jam: yes, true, for now
[09:41] <jam> though I'm reluctant to have lots of special code paths just for that.
[09:41] <axw> agreed
[09:45] <wallyworld_> i only put in the local hack cause we needed to cut a new release and time was running out
[09:46] <jam> wallyworld_: sure, but it was also supported because of questions about "should we really have HA with local", which seems to go around a bit in circles
[09:46] <wallyworld_> well yeah, but would be nice to have it to experiment, even wit the machine 0 limitation
[09:53] <perrito666> good morning everyone
[09:54] <voidspace> perrito666: morning
[09:56]  * perrito666 makes some effort to avoid falling asleep in the kb
[09:56] <jam> perrito666: at least those keys usually are pokey enough to help keep you awake :)
[10:06] <perrito666> are we doing the big team meeting?
[10:06] <jam> perrito666: for people that want to be there
[10:06] <voidspace> perrito666: yes, now
[10:07] <thumper> are you guys actually in the meeting?
[10:07] <thumper> I thought we were going to stop that one
[10:08]  * thumper wanders off for a bit
[10:08] <voidspace> thumper: we're doing it
[10:16] <voidspace> http://www.zdnet.com/canonical-juju-devops-tool-coming-to-centos-and-windows-7000029418/#ftag=RSS510d04f
[10:17] <voidspace> Juju on windows and CentOS!!
[10:17] <voidspace> we'd better make it happen then
[10:18] <voidspace> according to that article we've already done it...
[10:22] <natefinch> They were demoing Windows at ODS
[10:22] <voidspace> natefinch: cool
[10:27] <voidspace> anyone know the url to the github repo for docs?
[10:27] <voidspace> I'd like to add a note about the HA logging
[10:28] <perrito666> voidspace github.com/juju/docs iirc
[10:28] <lazyPower> github.com/juju/docs
[10:29] <voidspace> thanks
[10:29] <jam> voidspace: my understanding through the channels is that it is a bunch  of "if $PLATFORM" hacks, but does "work"
[10:29] <voidspace> jam: right
[10:32] <voidspace> what is evil nick's nick? (irc handle)
[10:32] <voidspace> jam: the article starts with
[10:33] <voidspace> " No news may have been more surprising than that Canonical had ported its Juju DevOps  program to its rival's operating systems: Red Hat's CentOS and Microsoft's Hyber-V and Windows Server 2012."
[10:33] <jam> evilnick, IIRC
[10:33] <voidspace> Certainly surprising to me that we've ported it to CentOS :-)
[10:33] <jam> voidspace: well the client probably almost "just works" there, but Mark was pretty clear that it is "in the next few weeks" and not "already working"
[10:33] <voidspace> Although later the article does say "Thanks to a customer request, Canonical will be releasing Juju for CentOS."
[10:33] <jam> though "in the next few weeks" is still pretty ambitious
[10:33] <voidspace> right, it's just typical tech-journal hyperbole
[10:34] <voidspace> yep :-)
[10:34] <jam> depending on your definition of "few"
[10:50] <voidspace> jam: we have an api call (server side implementation) that does it's permissions check with:
[10:50] <voidspace> "if !api.canModify {"
[10:50] <voidspace> what permission is that checking for?
[10:50] <voidspace> jam: answer when you have spare cycles... no rush
[10:51] <voidspace> I can provide more context to the question
[10:51] <voidspace> I think the specific test that is failing may not make sense any more
[10:51] <jam> voidspace: which set of code?
[10:51] <jam> rsyslog ?
[10:51] <voidspace> this is in state/apiserver/rsyslog/rsyslog.go
[10:51] <voidspace> so yes
[10:51] <jam> 		canModify:      authorizer.AuthEnvironManager(),
[10:52] <jam> voidspace: so this was checking whether you are allowed to do something like set the ca-cert
[10:52] <voidspace> the test is checking that calling SetRsyslogCert fails with a permissions error appropriately
[10:52] <jam> and only EnvironManagers (aka state servers) were supposed to be allowed.
[10:52] <voidspace> right, that's what I suspected
[10:52] <voidspace> the test does
[10:52] <voidspace> st.Rsyslog().SetRsyslogCert(coretesting.CACert)
[10:52] <jam> voidspace: we don't want generic Machine/Unit agents be abel to set it, but they need to be able to read it
[10:53] <jam> voidspace: sure, it should be done with an Authorizer that doesn't have AuthEnvironManager()
[10:53] <jam> If that API is exposed then we should test that !EnvironManagers get a permission failure trying to call it
[10:53] <voidspace> hmmm...
[10:54] <jam> voidspace: apiserver/testing.FakeAuthorizer generally gives you lots of ability to tweak things.
[10:54] <voidspace> jam: so the problem is that the test was previously doing "s.OpenAPIAsNewMachine(c, state.JobHostUnits)"
[10:54] <voidspace> but that was failing because we need a "real" state server in order to be able to access st.Rsyslog()
[10:55] <perrito666> bbl
[10:55] <voidspace> but changing it to JobManageEnvirons causes the test to fail because there is no permissions error
[10:55] <voidspace> so I think I need to create a state server, but then make this call from a unit
[10:55] <wallyworld_> fwereade: after the next meeting i'd like to have a quick chat about the BaseSuite stuff if you have some time
[10:55] <voidspace> jam: thanks
[10:56] <jam> voidspace: I don't quite understand what you mean about the real state server to access st.Rsyslog(), you can create a machine entity which has JobManageEnviron and then create *another* one that doesn't
[10:56] <voidspace> st.Rsyslog() fails with "no state servers can be found"
[10:56] <voidspace> because Rsyslog checks APIHostPorts and if this is empty that call errors
[10:57] <jam> voidspace: sure, there is a general thing that JujuConnSuite doesn't create a Machine-0 for you that has JobManageEnviron, you should be able to look around for tests that create one
[10:57] <jam> and then do that firsrt
[10:57] <jam> and then do OpenAPIAsNewMachine()
[10:57] <jam> and then the rest of the test probably doesn't need much changing.
[10:57] <voidspace> yep, that's what I meant - create a state server (and set address) but call Rsyslog from a machine with JobHostUnits
[10:58] <voidspace> and that now passes
[10:58] <jam> voidspace: right, so like state/apiserver/client/client_test.go line 2198 is creating machine0, but is connecting to the API server as Client
[10:58] <jam> voidspace: cheers
[10:59] <voidspace> no file should *ever* have a line 2198 :-D
[10:59] <natefinch> +100
[11:00] <voidspace> jam: I've done this
[11:00] <voidspace> https://pastebin.canonical.com/110265/
[11:00] <natefinch> I remember a 1000 line function from one of my early jobs...  now I can't imagine how it wasn't broken up
[11:00] <voidspace> jam: is s.State.AddMachine(...) preferable, or just a different spelling of the same thing?
[11:01] <jam> voidspace: I believe OpenAPIAsNewMachine does s.State.AddMachine behind the scenes, but then goes on and connects to stuff, which you don't actually use
[11:01] <jam> so just doing the s.State.AddMachine is prob better
[11:01] <voidspace> jam: right, I'll try that then - thanks
[11:02] <voidspace> to be fair, huge files are *less* of an issue for test files
[11:02] <voidspace> still not ideal though
[11:02] <voidspace> brb
[11:02] <jam> voidspace: I'd be happy with a "// ensure there is a machine-0 so we have an address to copy logs to"
[11:03] <voidspace> jam: yep, good call
[11:49] <voidspace> wwitzel3: ping
[12:07] <wwitzel3> voidspace: pong
[12:23] <jam> TheMue: do you feel like you have enough guidance to start working on cleaning up the giant agenda doc, or do you need some more discussion?
[12:25] <TheMue> jam: in my first step I’m running through the doc and make my notes what I think it is to change (from should/want to we do) and what is to cleanup
[12:25] <TheMue> jam: in a second run I would like to share it with you to discuss it
[12:26] <TheMue> jam: I’m currently working in a copy of that doc
[12:27] <jam> that sounds good
[12:27] <voidspace> wwitzel3: hey, hi
[12:27] <wwitzel3> voidspace: hangout?
[12:27] <voidspace> wwitzel3: so I have all tests passing in our branch
[12:27] <voidspace> wwitzel3: sure
[12:50] <voidspace> lunch
[13:27] <wwitzel3> voidspace: it ended up being a permissions issue
[13:27] <wwitzel3> voidspace: I pushed the changes, tested successfully with ec2 and maas
[13:28] <perrito666> jam: did yo really mean to invite me to this meeting? "Every 3 weeks from 23:00 to 00:00 on Wednesday (ART)"
[13:28] <jam> perrito666: I just sent out an email to canonical-juju explaining it
[13:28] <wwitzel3> voidspace: I'm going to start fleshing out some of the test cases a bit more and working on doc
[13:28] <jam> the idea is that the weekly meeting starts rotating by 8 hours
[13:28] <jam> so some of them you can't make
[13:28] <jam> hopefully most you can
[13:47] <bodie_> booya, gojsonschema now apache2 licensed
[13:54] <jcw4> bodie_: nice!
[14:08] <voidspace> wwitzel3: cool, I suspected as much
[14:09] <voidspace> wwitzel3: yup, MachineAgent *or* UnitAgent
[14:09] <wwitzel3> voidspace: yep
[14:09] <voidspace> I wondered if that would be the fix :-)
[14:09] <voidspace> wwitzel3: nice work, thanks
[14:09] <voidspace> grabbing coffee
[14:15] <voidspace> wwitzel3: I have some simple docs by the way
[14:15] <sinzui> jam, natefinch : is anyone about to look into bug 1319822
[14:15] <_mup_> Bug #1319822: lxc unit tests broken for trusty <lxc> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1319822>
[14:16] <voidspace> wwitzel3: http://pastebin.ubuntu.com/7467981/
[14:16] <sinzui> ^ telling my CI is mis-configured is an acceptable answer
[14:16] <voidspace> sorry about the line wrapping
[14:18] <wwitzel3> voidspace: cool, I just pushed some comment updates
[14:27] <natefinch> sinzui: seems it's likely an environmental issue, but I'm not sure exactly what's going on there
[14:28] <wwitzel3> voidspace: did the initial propose, figure people can start looking at it now while we button things up with doc
[14:28] <natefinch> fwereade: are you back?
[14:28] <voidspace> wwitzel3: ok
[14:28] <voidspace> cool
[14:29] <wwitzel3> natefinch, jam, fwereade, voidspace: https://codereview.appspot.com/94510043/ (rsyslog API/watcher changes), fixes bug #1310268
[14:29] <_mup_> Bug #1310268: rsyslog should accumulate on all state machines <debug-log> <ha> <juju-core:In Progress by wwitzel3> <https://launchpad.net/bugs/1310268>
[14:29] <sinzui> natefinch, the trusty unit-tests setup forces mongodb-server. I don't think it is a factor. trusty /could/ get a newer lxc, but I hasn't
[14:30] <wwitzel3> voidspace: I'm going to test what happens with multiple units --to the same machine, then doing ensure-availability
[14:30] <voidspace> great
[14:30] <wwitzel3> voidspace: also that doc you wrote LGTM
[14:30] <voidspace> wwitzel3: I'll go though checking our test coverage
[14:30] <voidspace> wwitzel3: cool - I sent an email to juju list asking where it should go, but I didn't see the email land
[14:31] <voidspace> wwitzel3: ah, it did - curtis replied
[14:32] <voidspace> and Nick
[14:32] <voidspace> I'll put those in a github issue
[14:34] <natefinch> sinzui: you on the cross team call?
[14:37] <sinzui> I am
[14:37] <mattyw> natefinch, after the call cmars has suggested you guys could do with some help on the ha work, ping me when you have a moment and we'll see if there's anything I can help with
[14:37] <natefinch> mattyw: that would be awesome
[15:23] <natefinch> I'm off to pick up some chicks (of the baby chicken variety).  Back in like an hour and a half-ish.
[15:24] <perrito666> I must say natefinch has the best bbl messages
[15:27] <wwitzel3> perrito666: haha, yeah
[15:28] <perrito666> mm, what is the proper way to make juju look for juju-local in gopath?
[16:34] <voidspace> jam: ping
[16:56] <perrito666> mm, juju local is broken?
[16:56] <perrito666> I mean in trunk
[17:25] <voidspace> perrito666: local provider or the juju-local package?
[17:25] <perrito666> voidspace: no, I built the one from trunk and am using that, but I suspect is not working so well
[17:25] <voidspace> perrito666: juju local what though?
[17:26] <voidspace> perrito666: I thought juju-local was just an empty package to declare dependencies
[17:26] <voidspace> perrito666: what on trunk did you build/
[17:26] <voidspace> ?
[17:27] <perrito666> voidspace: I meant juju-local the binary
[17:27] <perrito666> :)
[17:27] <voidspace> oh
[17:27] <voidspace> heh
[17:28] <voidspace> perrito666: fair enough :-)
[17:28] <perrito666> which bootstraps but the bootstraped env has address localhost, which is wrong
[17:29] <voidspace> hmmm... doesn't sound good
[17:29] <voidspace> but I'm EOD
[17:29] <perrito666> voidspace: have a nice day
[17:29] <voidspace> perrito666: thanks
[17:34] <natefinch> I'm back, sadly without chicks.
[17:35] <perrito666> natefinch: eggs, a hot lamp and time?
[17:36] <natefinch> perrito666: haha, no.  When I called, they said the chicks had come in, but it turns out only half their order had come in - sadly, the half that had the varieties we were not interested in
[17:36] <perrito666> natefinch: I am slightly curious, what are you going to do with the chicks?
[17:40] <natefinch> perrito666: they're egg layers.  We eat some and sell most of them to a local hostel
[17:42] <perrito666> natefinch: you are a full fledged farmer
[17:44] <natefinch> perrito666: heh... I have chickens and bees and a vegetable garden.  Not really a farmer, but working my way there.  Someday we'll have goats and maybe pigs... right now the kids kinda make that too much to take on.
[17:44] <mattyw> natefinch, that sounds like farming to me
[17:45] <TheMue> natefinch: and don’t forget your coffee
[17:45] <TheMue> yummy
[17:45] <mattyw> does your vegetable garden require a tractor to sow?
[17:46] <mattyw> natefinch, I'm going to be ending my day soon, do you have a few minutes to talk about ha work items you need help with?
[17:46] <perrito666> natefinch: heh, too much work, I only do bread and yogurt
[17:46] <natefinch> mattyw: haha... I wish, then I'd have an excuse to buy a tractor ;)
[17:46] <natefinch> TheMue: I roast coffee, but I don't grow it, that hardly counts :)
[17:46] <natefinch> mattyw: yes, sorry I didn't get to you earlier.
[17:46] <TheMue> natefinch: I know, but it’s still very special
[17:47] <mattyw> natefinch, no problem at all
[17:48] <natefinch> perrito666: btw, are you working on that APIWorker thing? If so, you should assign the card to yourself and put it in doing
[17:48] <perrito666> natefinch: yup sorry
[17:49] <natefinch> mattyw: we have our kanban board here, my team is Moonstone, so you can see the stuff that is in the "2 week planning" which is essentially the "Todo" lane (ignore the actual todo lane, that's not in current use) https://canonical.leankit.com/Boards/View/103148069#workflow-view
[17:50] <natefinch> mattyw: anything not assigned to anyone is up for grabs.
[17:50] <mattyw> natefinch, it appears that my leankit account has been deactivated (despite me asking it not to be)
[17:57] <natefinch> mattyw: doh, I'll talk to IS about getting it set back up
[17:59] <natefinch> mattyw: you can look here instead, this is basically the same stuff: https://docs.google.com/a/canonical.com/document/d/17yV2hZHhTch7fn33s3qJoT3qXJrXSeD40z8k7Rt90I8/edit
[17:59] <natefinch> mattyw: how familiar are you with the juju-core code?
[18:02] <natefinch> mattyw: we can talk tomorrow too, if that's easier.  I don't want to keep you past EOD
[18:05] <wwitzel3> natefinch: https://codereview.appspot.com/94510043/ when you have a chance (rsyslog stuff from voidspace and myself)
[18:05] <natefinch> wwitzel3: sweet, I'll take a look
[18:07] <mattyw> natefinch, I'm "hopefully" in the process of getting my leankit account setup again
[18:08] <natefinch> mattyw:
[18:08] <natefinch> cool
[18:08] <natefinch> somehow hit enter rather than space... stupid fingers
[18:09] <perrito666> natefinch: they are close... :p
[18:10] <mattyw> natefinch, I've done some stuff with the api before, and a little bit of stuff around the service docs in the state server, but that's about it
[18:13] <mattyw> natefinch, yeah, if it's ok with you can we talk tomorrow morning (your time) about ha and I'll pick something up
[18:13] <natefinch> mattyw: that's cool.  Have a good evening, we can talk tomorrow.
[20:54] <bodie_> fwereade, the thinking behind "actionsspec" was that Actions would be the list of actions on the state
[20:54] <bodie_> I guess a charm can't have a list of actions :)
[20:55] <fwereade> bodie_, hey, I'm here now for a bit
[20:55] <fwereade> bodie_, need to push that code for jcw4, it depends on some more code I should push, need a few mins
[20:55] <bodie_> right on.  I'm still mid-stride with the last bits here in state
[20:55] <bodie_> added actions.yaml, reader, and charm member
[20:56] <bodie_> I don't want it to become another monolithic commit but adding it as a piece of the Charm interface has a pretty long-reaching effect
[20:56] <bodie_> however I think I've been able to pare it down significantly from what we had before
[21:02] <fwereade> bodie_, you could rationally add the types and reader to the charm package without needing to hit anything else -- not even reading them when you read a charm
[21:02] <bodie_> ah
[21:02] <fwereade> bodie_, adding a type and actually using it in 2 CLs generally makes me pretty happy even :)
[21:02] <bodie_> ^_^
[21:03] <bodie_> should I snip the other bits out then?  I figured the mission was "add Actions to Charm"
[21:03] <fwereade> bodie_, and inevitably the second CL includes a tweak or 2 to adapt to reality, but that's just fine
[21:03] <bodie_> which, I think is mostly pushed through by now
[21:03] <fwereade> bodie_, sure, but the more and smaller the steps you take to get there the smoother everything usually goes -- but if it's bigger don't let that stop you either
[21:03] <bodie_> I can of course yoink the relevant bits but I think this is pretty sane
[21:03] <bodie_> okay, cool
[21:04] <menn0> hi ppl.
[21:04] <fwereade> menn0, heyhey
[21:04] <menn0> fwereade: do you not sleep? :-p
[21:04] <fwereade> menn0, I'm well behind wallyworld_ in the no-sleep stakes :)
[21:04] <fwereade> menn0, and actually I had a nap this afternoon so I'm feeling a bit guilty about that ;)
[21:05] <bodie_> no rest for the wicked!
[21:05] <menn0> fair enough
[21:05] <menn0> question: I picked up this yesterday but it appears that it's already been fixed. https://bugs.launchpad.net/juju-core/+bug/1194481
[21:05] <_mup_> Bug #1194481: Can't determine which relation is in error from status <hours> <observability> <ui> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1194481>
[21:06] <fwereade> menn0, hmm, I knew we recorded the necessary information, didn't remember that we actually exposed that in status
[21:06] <fwereade> menn0, do we expose the relation id, or just the name?
[21:06] <menn0> actually, now that I re-read the ticket... I think I understand the problem more.
[21:07] <menn0> the full hook name is given but the relation isn't
[21:07] <menn0> nevermind
[21:07] <fwereade> menn0, knowing that mysql's "db" relation has an error is not quite all we need; it might be driving wordpress, mediawiki, etc
[21:07] <fwereade> menn0, cool
[21:07] <fwereade> menn0, that info is in the status data dict
[21:07] <menn0> fwereade: yeah but the StatusData map isn't pushed through the API yet
[21:08] <thumper> o/
[21:08] <menn0> i'll sort that out!
[21:08]  * thumper has a haircut appt shortly
[21:08] <menn0> thumper:   \o
[21:08] <fwereade> thumper, heyhey
[21:08] <fwereade> menn0, heh, "dict", my python is showing
[21:09] <menn0> fwereade: I noticed but chose not to tease you :)
[21:10] <fwereade> jcw4, https://codereview.appspot.com/94540043 is a quick hack that I'm not yet sure is a good idea; but it does involve adding a new cleanup type, as I suspect we'll need to deal with actions referencing dead units
[21:11] <jcw4> fwereade: thanks~
[21:12] <menn0> fwereade: StatusData doesn't have the relation name either so I may have to fix that. Or is it easy to derive the relation name from the id?
[21:12]  * thumper back soonish
[21:13] <fwereade> menn0, name is a tricky concept in a relation, the two sides might call it different things
[21:13] <fwereade> menn0, but, yes, you can look up relations be id and get a human-readable name out
[21:13] <fwereade> menn0, eg "wordpress:mysql mysql:db"
[21:13] <bodie_> fwereade, I'm starting to think this MR is going to be a little out of control, but again, broad scope.... well, maybe you can give me a little feedback in a couple of minutes here
[21:14] <fwereade> menn0, that's a pair of "endpoints" -- not sure if you cast an eye over doc/glossary.txt?
[21:14] <menn0> fwereade: that makes sense. I guess I need to figure out if juju status has enough information to figure out the appropriate endpoint name from just the relation-id and the unit.
[21:15] <menn0> fwereade: or if I need to put more in to the StatusData map so that it can show the required info
[21:15] <menn0> fwereade: yep, I have read glossary.txt
[21:15] <fwereade> menn0, you shouldn;t need more in the statusdata map -- just get it if you need it when you're generating the actual status
[21:16] <menn0> fwereade: cool
[21:16] <jcw4> fwereade: per your cleanup code... I would add code to cleanupDyingUnit for scrubbing Actions?
[21:16] <fwereade> jcw4, well, it'd be a deadUnit cleanup, but yeah
[21:16] <jcw4> bingo
[21:17] <jcw4> fwereade: got it
[21:17] <menn0> fwereade: first step then is to thread StatusData through the API, which I think I've almost done
[21:18] <jcw4> fwereade: should I merge your branch in, or just emulate it and we'll merge before landing?
[21:19] <fwereade> jcw4, I would just clone the structure, all the *actual* code will be different I think
[21:20] <fwereade> menn0, not 100% sure there -- see state/apiserver/client.go:525
[21:20] <jcw4> fwereade: ok so by clone you mean copy and modify for Dead vs. Dying?
[21:20] <fwereade> menn0, one thing we did discuss at the sprint -- but I forget under what heading -- was the unification of the AllWatcher data stream and the Status result
[21:21] <fwereade> menn0, they're different for no good reason ATM
[21:22] <fwereade> menn0, if (as I think it is) it's in the AllWatcher stream, consider poking it into status in a vaguely similar way -- but *consider*, it might be crazy/impossible to do so
[21:22]  * menn0 looks at code. knows nothing about AllWatcher stream.
[21:22] <fwereade> menn0, ideally we'll let the two formats converge and have CLI status just be a wrapper converting exactly the same data into the existing output format
[21:23] <fwereade> menn0, but I don;t want to trigger crazy refactorings in the course of this bug fix
[21:23] <fwereade> menn0, just do it if it's easy :)
[21:23] <fwereade> jcw4, I think you'll find there;s little that actually gets copied
[21:23] <menn0> fwereade: I will have a go
[21:23] <fwereade> jcw4, a branch in the switch, but new and different code for (1) queuing it and (2) handling it
[21:24] <jcw4> fwereade: yeah.. okay -- the code helps tremendously as a guide
[21:24] <fwereade> jcw4, cool
[21:24] <menn0> fwereade: that line number in state/apiserver/client.go doesn't seem at all relevant to our discussion. It lands me half way down GetServiceConstraints
[21:24] <menn0> fwereade: I've just pulled to be sure
[21:24] <fwereade> menn0, balls, sorry: /client/status.go
[21:26] <fwereade> menn0, FWIW there's another TODO in that about maybe not hitting the DB at least twice for each relation -- might be good to address that one tbh, rather than worrying about AllWatcher now
[21:27] <menn0> fwereade: I've already spiked to address that TODO in status.go :)
[21:27]  * fwereade cheers at menn0
[21:27] <menn0> fwereade: I'll check out the other TODO as well
[21:33]  * menn0 is having fun
[21:39]  * fwereade is happy
[21:40]  * fwereade maybe bbiab, but most likely going to sleep
[22:02] <waigani> menn0: what bug are you working on?
[22:03] <menn0> waigani: https://bugs.launchpad.net/juju-core/+bug/1194481
[22:03] <_mup_> Bug #1194481: Can't determine which relation is in error from status <hours> <observability> <ui> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1194481>
[22:14] <thumper> rick_h_: around?
[22:14] <thumper> rick_h_: I'd like to understand some more the charmstore work
[22:15] <thumper> also...
[22:15] <thumper> damnit
[22:15] <thumper> I had a great idea for an email I was going to write to the juju-dev list outlining something
[22:15] <thumper> and now it has gone
[22:15]  * thumper sits back and thinks through what he was thinking through
[22:16] <thumper> oh
[22:16] <thumper> that was it
[22:16] <thumper> yay
[22:16] <thumper> note to self: email juju-dev about schema upgrade process
[22:23] <rick_h_> thumper: around
[22:23] <thumper> rick_h_: got time?
[22:23] <rick_h_> thumper: sure, sec
[22:24] <thumper> rick_h_: https://plus.google.com/hangouts/_/gsd6yrioblijf2oz3fvdnyesjma?hl=en
[23:44] <thumper> davecheney: re: https://github.com/juju/errgo/pull/2/files I don't get why this fixes the errgo tests, but when called from juju/errors it behaves correctly (given the extra generated method that we now side step)
[23:44] <thumper> davecheney: can you explain it?
[23:50] <thumper> is it related to the testing module?
[23:50] <thumper> that is the only other difference between the tests, juju/errors uses gocheck whereas juju/errgo just uses the builtin testing module