[00:37] <thumper> wallyworld: I can chat earlier if you can
[00:37] <wallyworld> thumper: sure,now?
[00:37] <thumper> yeah
[01:29] <davecheney> func (b blocks) add(block block)
[01:30] <davecheney> hmmm
[03:33] <davecheney> thumper: how do I set debugging level to trace on an environment
[03:33] <davecheney> (you can tell it's been a long time since I did this)
[03:33] <thumper> davecheney: a running environment?
[03:33] <davecheney> i haven't deployed yet
[03:34] <davecheney> actually, don't worry
[03:34] <davecheney> i kjnow the line I want to see
[03:34] <thumper> juju set-env logging-config=juju=trace
[03:34] <davecheney> i'll just make it an error
[03:34] <thumper> you can set an environment variable
[03:34] <davecheney> then I don't ahve to deal with trillions of lines of trace
[03:34] <thumper> export JUJU_LOGGING_CONFIG=juju=debug,juju.something.specific=trace
[03:34] <natefinch-afk> logging-config: "<root>=DEBUG;juju.worker.leadership=WARNING;juju.trace=WARNING;juju.worker.peergrouper=INFO;juju.worker=ERROR;juju.apiserver=TRACE
[03:35] <natefinch-afk> (in environments.yaml)
[03:35] <thumper> that is another way
[03:35] <davecheney> i'll just hack the error to report at ERROR level
[03:35] <thumper> :)
[03:35] <natefinch> also works :)
[03:35] <davecheney> i don't want to have to deploy twice if I screw it up
[03:35] <davecheney> all I want to see is the specific line failing, then I can check my fix
[03:39] <mup> Bug #1536885 opened: github.com/juju/juju/cmd/jujud/agent fails frequently with go 1.5 <juju-core:New> <https://launchpad.net/bugs/1536885>
[03:41] <davecheney> lucky(~/devel/swift-test) % juju bootstrap -v
[03:41] <davecheney> Bootstrapping environment "ap-southeast-2"
[03:41] <davecheney> Bootstrap failed, destroying environment
[03:41] <davecheney> ERROR failed to bootstrap environment: cannot read product data, invalid URL "https://juju-dist.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju:devel:tools.sjson" not found
[03:43] <menn0> thumper: if you have a chance could you take a look at http://reviews.vapour.ws/r/3541
[03:43] <menn0> thumper: it's quite different from when you last looked at it.
[03:44] <menn0> thumper: one more issue from Will to address and then it's ready (pending any further review feedback)
[03:44] <thumper> k
[03:56] <cherylj> hey natefinch, regarding your review, I still think it makes sense to test for content type since that's something generated in the functionality we're testing.  It just happens it can be one of two things, depending on where the tests are running
[04:00] <lazypower> davecheney I just ran into that myself
[04:01] <lazypower> davecheney however, it doesn't appear ot be holding anything up. I still have services coming online... but i did bootstrap with --upload-tools
[04:01] <natefinch> cherylj: yeah, sorry, saw your comment earlier
[04:01] <natefinch> cherylj: do you know why we return two different content types?
[04:05] <davecheney> lazypower: ame
[04:05] <davecheney> lazypower: same
[04:08] <davecheney> http://paste.ubuntu.com/14595278/
[04:08] <davecheney> ^ uhhh
[04:10] <cherylj> natefinch: yeah, I had asked sinzui about it.  something about the package used by centos handling javascript differently.  Sorry it's late and now I don't completely remember what he said
[04:10] <cherylj> but it seemed satisfactory at the time :D
[04:21] <mup> Bug #1536819 changed: Feature Request: Storage support for openstack provider <juju-core:Invalid> <https://launchpad.net/bugs/1536819>
[04:24] <mup> Bug #1536819 opened: Feature Request: Storage support for openstack provider <juju-core:Invalid> <https://launchpad.net/bugs/1536819>
[04:24] <davecheney> where does the leadership manager worker run ?
[04:24] <davecheney> is it on machine 0 ?
[04:25] <davecheney> or is it on every machine that is a component of a leadership charm
[04:26] <thumper> davecheney: probably managed by the "master" state server machine
[04:26] <thumper> which will start with machine 0
[04:26] <davecheney> ok
[04:26]  * thumper has had enough of today
[04:26] <davecheney> i have a fix for the bug
[04:26] <thumper> awesome
[04:26] <davecheney> and i appears to work
[04:26] <thumper> time to start drinking
[04:26] <davecheney> bootstraping now
[04:26] <thumper> hazaah
[04:26] <thumper> good luck
[04:26] <davecheney> but I'm having trouble writing up the description as how the lease stuff works is not entirely clear in my head
[04:27] <davecheney> but if the lease manager runs on machine 0
[04:27] <davecheney> not the actual machien holding the lease
[04:27] <davecheney> that makes sense
[04:27] <mup> Bug #1536819 changed: Feature Request: Storage support for openstack provider <juju-core:Invalid> <https://launchpad.net/bugs/1536819>
[04:31] <axw> wallyworld: how does changing the name to ModelTag stop things from compiling?
[04:32] <wallyworld> # github.com/juju/names
[04:32] <wallyworld> ./model.go:27: ModelTag is not a type
[04:32] <wallyworld> nfi
[04:33] <axw> wallyworld: that's because you've got a variable called ModelTag
[04:33] <wallyworld> oh ffs
[04:33] <wallyworld> sigh, ignore me
[04:34] <wallyworld> too many concurrent things
[04:34] <axw> wallyworld: just going to have something to eat, will you be available for 1:1 soonish?
[04:34] <wallyworld> sure
[04:34] <axw> ok, bbs
[04:38] <davecheney> soooo, leadership doesn't use a watcher ...
[04:48] <davecheney> http://reviews.vapour.ws/r/3605/
[04:48] <davecheney> for review, still testing
[04:51] <mup> Bug #1535916 changed: juju upgrade-charm should recognize the force flag <adoption> <compatibility> <juju-core:Invalid> <https://launchpad.net/bugs/1535916>
[04:59] <axw> wallyworld: ready now?
[04:59] <wallyworld> axw: ok, give me 5
[04:59] <axw> wallyworld: sure, ping when you're there
[05:00] <davecheney> http://paste.ubuntu.com/14595610/
[05:00] <davecheney> well shit
[05:00] <davecheney> and now AWS has locked me out for rate limit abuse
[05:18] <wallyworld> axw: there now
[09:05] <frobware> voidspace, fyi maas-spaces is cursed - http://reports.vapour.ws/releases/3530
[09:15] <frobware> voidspace, btw. I didn't look at the detail, just noted the failure message in my inbox
[09:22] <voidspace> frobware: ok
[09:22] <voidspace> frobware: looking at a master merge last night, merging the test code itself is straightforward - but the test *scripts* are not so trivial (at least to me)
[09:22] <voidspace> frobware: you'd probably find it a lot easier
[09:23] <frobware> voidspace, I'm in the middle of the 3 bugs right now....
[09:23] <voidspace> frobware: ok, the longer we leave it the worse it gets though
[09:23] <frobware> voidspace, can we HO and look at the detail?
[09:24] <voidspace> frobware: let's do it after standup, I still need coffee
[09:24] <voidspace> maas-spaces hasn't been blessed since December 9th!
[09:24] <frobware> voidspace, I don't want to leave it. equally, I don't want to stash what I'm currently doing.
[09:24] <voidspace> not as bad as it could be...
[09:24] <frobware> voidspace, yep!
[09:25] <voidspace> centos & windows unit tests and go-1.5 on trusty failures
[09:25] <voidspace> looks like the only *voting* failure is the windows one
[09:26] <voidspace> metadata failures, not code we've touched!? (I don't think)
[09:26] <voidspace> I'll look at the other curses and see if they're consistent
[09:27] <voidspace> also in the middle of the api stuff
[09:29] <voidspace> frobware: most of the curses prior to the *most* recent are "stale version"
[09:29] <voidspace> I'll have to ask mgz what that means
[09:30] <voidspace> frobware: those windows tests passed on master though (even though master is also cursed)
[09:30] <frobware> voidspace, right. and this is why I recently read somewhere are sample size of a BLESSED run should be > 1. This failure may be transient.
[09:30] <frobware> s/read/said/
[09:31] <voidspace> frobware: right
[09:31] <voidspace> frobware: many of the tests are still pending on that run
[09:31] <voidspace> frobware: we'll need another run to see if that windows failure is genuine
[10:01] <voidspace> dooferlad: frobware: stdup?
[10:01] <frobware> voidspace, ah, friday. wrong link. omw...
[10:12] <voidspace> mgz: ping
[10:15] <frobware> voidspace, this one? http://reviews.vapour.ws/r/3564/
[10:44] <voidspace> dooferlad: frobware: huge again!
[10:44] <voidspace> dooferlad: frobware: http://reviews.vapour.ws/r/3609/
[10:45] <voidspace> running tests
[10:45] <frobware> voidspace, this is motivation for us to clean up and get our stuff back into master.
[10:45] <voidspace> yep
[10:46] <voidspace> mind you, a big chunk of that diff is the legacy azure provider being removed
[10:59] <voidspace> frobware: dooferlad: clean unit test run on the merged branch
[11:28] <frobware> I'm trying to submit a PR but the subsequent RB is always empty (http://reviews.vapour.ws/r/3612/) -- anybody else see this behaviour?
[11:51] <frobware> voidspace, I was trying to run the unit tests on your -2 merge branch. Currently fails for me.
[12:04] <frobware> voidspace, dooferlad: http://reviews.vapour.ws/r/3614/
[12:05] <frobware> voidspace, will take another look at your merge -2 branch now.
[12:30] <frobware> voidspace, unit test pass for me in your merge -2 branch.
[12:54] <voidspace> frobware: cool
[13:43] <mgz> voidspace: when did you guys last merge master?
[13:44] <mgz> and did you merge a blessed rev or just what happened to be tip?
[14:40] <voidspace> mgz: well, we merged very recently - but there's already a stack more changes
[14:41] <voidspace> mgz: and we just merged tip
[14:41] <voidspace> mgz: we just got a test run (cursed - windows unit tests failed in code unrelated to our changes)
[14:41] <voidspace> mgz: but *before* we merged master there was a long gap between us and master
[14:41] <voidspace> mgz: and all the test runs came up with "stale version"
[14:43] <mgz> voidspace: I'm asking because the windows test failur was only very briefly on master
[14:43] <mgz> and is fixed on tip
[14:44] <voidspace> mgz: ah, cool
[14:44] <voidspace> mgz: we're about to merge again
[14:44] <voidspace> mgz: and would appreciate a new CI run when that's done
[14:45] <voidspace> dooferlad: frobware: can I have a +1 on my merge branch?
[14:50] <frobware> voidspace, done.
[14:50] <frobware> voidspace, could you take a look at http://reviews.vapour.ws/r/3614/
[15:02] <mup> Bug #1537082 opened: Cannot use devel/proposed agent streams with daily stream for xenial <bootstrap> <streams> <juju-core:Triaged> <juju-release-tools:Triaged> <https://launchpad.net/bugs/1537082>
[15:14] <beisner> frobware, cherylj, mgz - 24hrs into exercising 1.25.3 @ uosci, smooth sailing :-)
[15:14] <cherylj> beisner: yay!!
[15:45] <voidspace> frobware: looking
[15:47] <voidspace> frobware: ooh, O(n^2) append function
[15:47] <voidspace> ;-)
[15:49] <voidspace> frobware: LGTM, the Python is straightforward
[15:57] <frobware> voidspace, yep. the alternative is ordered set. or dict. and importing collectiosn. can do, but don't think we have perf issues.
[15:57] <frobware> voidspace, wary if importing anything not does not work on series >= precise.
[16:35] <voidspace> frobware: it's fine, it won't be an issue
[16:36] <voidspace> mgz: will we get a new maas-spaces CI run automatically, or do you have to kick it off for us?
[16:36] <voidspace> mgz: frobware: because the latest master merge has landed and we'd like a new one please :-)
[16:37] <frobware> voidspace, yep looking forward to monday starting out blessed! :-D
[16:37] <voidspace> hehe, we can hope
[16:38] <frobware> voidspace, I even bootstrapped with your latest merge
[16:39] <mgz> voidspace: it will happen, but I'll manually bump
[16:39] <natefinch> katco: good question on using tags...
[16:39] <katco> natefinch: if i remember correctly they're supposed to be constrained to the api portion
[16:39] <katco> natefinch: and strings are fine elsewhere
[16:40] <natefinch> katco: I think you're right, though I really dislike the policy behind that second statement...
[16:42] <natefinch> katco: I think we have a ton of places in the code where string actually means "this is an ID of an object and must be able to be parsed back into a tag" except there's nothing actually indicating or enforcing that
[16:42] <natefinch> except perhaps having id on the end of the variable name :/
[16:45]  * perrito666 is under an AC and still a little hot... sometimes I really hate this country
[16:46] <natefinch> perrito666: it's -8°C here... (not inside, of course)
[16:46] <perrito666> natefinch: last night, at 1AM it was 30C here
[16:48] <frobware> voidspace, interestingly my PR caused a test failure. http://juju-ci.vapour.ws:8080/job/github-merge-juju/6070/console
[17:32] <mup> Bug #1537152 opened: Can't re-create a model <juju-core:New> <https://launchpad.net/bugs/1537152>
[17:34] <voidspace> frobware: that looks spurious, retry
[17:34] <voidspace> frobware: I've had that before
[17:35] <mup> Bug #1537152 changed: Can't re-create a model <juju-core:New> <https://launchpad.net/bugs/1537152>
[17:41] <mup> Bug #1537152 opened: Can't re-create a model <juju-core:New> <https://launchpad.net/bugs/1537152>
[17:50] <mup> Bug #1537153 opened: juju deploy --config option ignored when deploying a bundle <juju-core:New> <https://launchpad.net/bugs/1537153>
[19:03] <bdx> charmers, SOS --> https://bugs.launchpad.net/charm-helpers/+bug/1534819
[19:03] <mup> Bug #1534819: FetchHandler charmhelpers.fetch.giturl.GitUrlFetchHandler not found <Charm Helpers:New> <https://launchpad.net/bugs/1534819>
[20:00] <natefinch> katco: aww man, I missed that you could request to view resources for a specific unit, not just a service... didn't notice it until I was reading your user stories.
[20:03] <katco> natefinch: not surprising... i think that is a farily new addition (maybe in capetown)
[20:04] <natefinch> katco: revision history says it's been there since December 17th... I must have just glazed over it somehow
[20:04] <natefinch> katco: definitely the nice thing about having a more explicit, verbose set of user stories - harder to miss stuff
[20:05] <natefinch> as opposed to missing "[/unit]" in a huge document :)
[20:05] <katco> natefinch: yeah maybe that's what it is. alexisb called it out specifically in her notes, and as i was reviewing the spec to make the user stories i called it out specifically
[20:09] <natefinch> katco: what happens if you do juju resources --verbose mydb/0 ?
[20:10] <katco> natefinch: undefined as of yet
[20:10] <katco> natefinch: error
[20:26] <mup> Bug #1536819 opened: Feature Request: Storage support for openstack provider-specific config parameters <juju-core:Triaged> <https://launchpad.net/bugs/1536819>
[20:29] <perrito666> blah is a controller, use destroy-controller is perhaps the most anoying error We have
[20:30] <natefinch> oh, I'm sure we have worse errors than that
[20:30] <perrito666> that one is annoying
[20:30] <natefinch> what was that in response to you doing?
[20:30] <perrito666> you know what it is, you know what I want to do withit, dont get semantic on me
[20:31] <perrito666> natefinch: destroy-environment blah
[20:31] <natefinch> destroy controller sounds like a command you should never have to type
[20:33] <natefinch> we need a better name for what we now call environment
[20:33] <natefinch> I thought controller meant the state server(s)
[20:35] <natefinch> bleh
[20:39] <natefinch> perrito666: maybe we just need a destroy blah command
[22:54] <mup> Bug #1536215 changed: 1.25.0: deployment times out - system is deployed successfully by maas 1.9 but juju state never transitions from pending <oil> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1536215>