[00:04] <redir_> thumper: I am about eod and haven't been able to reproce the race in bug #1579051 . Looking through the test my best guess at this point is https://goo.gl/zmw7u8
[00:04] <mup> Bug #1579051: Race in juju/controller/destroy and TestDestroyCommandConfirmation <blocker> <ci> <intermittent-failure> <race-condition> <regression> <juju-core:In Progress by reedobrien> <https://launchpad.net/bugs/1579051>
[00:05] <thumper> redir_: ta
[00:05] <redir_> thumper: I understand from wallyworld you would be looking at that today
[00:05] <thumper> redir_: will do
[00:06] <thumper> redir_: not sure it is that
[00:06] <thumper> pushing onto a channel doesn't need a lock
[00:06] <thumper> unless the channel was created after the last sync point
[00:06] <thumper> which isn't the case here
[00:10] <redir_> thumper: OK. best wrong guess.
[00:15] <perrito666> redir_: it seems to be related on the fact that the tests are writing on dummy.dummy.ops
[00:15] <perrito666> I am just guessing from a pass over the code
[00:16] <perrito666> that might explain the fact that its intermittent, the order in which tests are run
[00:17] <perrito666> redir_: but someone that knows a bit more about the underlying machinery in go should chime on that
[00:17] <perrito666> davecheney: ?
[00:20] <thumper> ok, using davecheney's stress script with the race flag, I have the race condition regenerated
[00:20]  * thumper looks deeper
[00:21] <perrito666> thumper: I put my coins in too many people suspiciously writing on that shared object plz share the result if you find it :p
[00:27] <redir_> perrito666: I figured it was the estate.name read in the anonymous func
[00:27]  * redir_ wants davecheney's stress script
[00:28] <thumper> ugh... reminded that there is global state
[00:33] <thumper> ok, I got this
[00:37]  * redir_ lurks
[00:39] <thumper> redir_: wanna see?
[00:40] <redir_> thumper: yes
[00:40] <thumper> pushing now
[00:40] <redir_> cool
[00:40] <redir_> thumper: there's another that I was solving by pure WAG at http://reviews.vapour.ws/r/4813/
[00:41] <thumper> http://reviews.vapour.ws/r/4815/diff/#
[00:42] <thumper> ugh
[00:42] <thumper> spotted a typo
[00:43] <thumper> menn0: http://reviews.vapour.ws/r/4815/diff/#
[00:43] <redir_> Um, that looks a lot like https://goo.gl/zmw7u8
[00:43] <redir_> thumper: ^ but with a fine comment
[00:44] <redir_> but whatevs
[00:44] <redir_> is there any docs or pointers to the stress script you used?
[00:44] <redir_> thumper: ^
[00:45] <redir_> and thanks for sharing.
[00:45] <menn0> thumper: I remember reviewing redir_'s change recently which is the same as yours
[00:46] <thumper> heh
[00:46] <thumper> I am so tired
[00:46] <redir_> menn0 yesterdays was a different one, which didn't entirely fix it. There's an additional change for that at http://reviews.vapour.ws/r/4813/
[00:47] <redir_> a different race
[00:47] <thumper> you ar right...
[00:47] <thumper> redir_'s fix is the same
[00:47] <thumper> I just added more of a comment :)
[00:47] <thumper> and I have confirmed it fixed it
[00:47] <menn0> ok cool
[00:47] <menn0> well the comment is good
[00:48] <redir_> sadly I don't know if I am fixing them, because I can't repro them
[00:48] <menn0> and redir_'s additional changes need to go in too
[00:48]  * redir_ goes EoD
[00:49] <redir_> see you tomorrow #juju-dev
[00:56] <natefinch> mwhudson: ha, thanks for proposing that fix
[00:56] <natefinch> mwhudson: I don't know how they can live like that
[00:57] <mwhudson> natefinch: i'm pretty sure last time i looked at it, half the packages in git didn't compile
[00:58] <mwhudson> the problem in that issue makes the packaging fiddly, which is how i ran into it
[01:00] <natefinch> mwhudson: I can understand having a lot of junk shoved in closets, but when the window in the front door is broken... geez, just fix it.
[01:11] <natefinch> lol, 2 failed uniter tests overflowed the default 3000 line buffer in my windows command prompt
[01:12] <natefinch> and by lol, I mean, goodbye 15 minutes
[01:21] <perrito666> natefinch: oh, never run tests in windows without > blah.log
[01:21] <natefinch> perrito666: yeah, evidently
[01:21] <perrito666> then you can read that with notepad :p
[01:22] <natefinch> it would be funny if it weren't so sad
[01:23] <natefinch> perrito666: I'm just going to install vs code on this machine
[01:24] <natefinch> sinzui: what's with the windows apiserver/service bug getting marked fixed released?
[01:25] <natefinch> this one: https://bugs.launchpad.net/juju-core/+bug/1580184
[01:25] <mup> Bug #1580184: Timeout in github.com/juju/juju/apiserver/service on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1580184>
[01:26] <perrito666> I actually code on windows when fixing windows bug
[01:26] <natefinch> perrito666: exactly, which is why I am going to put vscode on that VM :)
[01:27] <perrito666> I did the same :)
[01:27] <bradm> I've got a juju subordinate charm stuck in allocating, I can't even see references to it in the juju logs - any ideas how I can get it moving again?  or destroy it so I can redeploy?
[01:30] <natefinch> bradm: juju destroy-service should work, I would think?
[01:31] <davecheney> redir: http://dave.cheney.net/2013/06/19/stress-test-your-go-packages
[01:31] <davecheney> sorry for the delay, the internet was totally crapped out here
[01:31] <bradm> natefinch: its a subordinate, and I want the rest of the others to stay
[01:32] <natefinch> bradm: so just one unit of it is stuck?
[01:32] <bradm> natefinch: I tried juju destroy-unit and it told me to bugger off, its a subordinate
[01:32] <bradm> natefinch: yeah
[01:32] <bradm> natefinch: landscape-client, so there's basically subordinates everywhere
[01:32] <natefinch> bradm: ahh, yeah, I see a caveat in the bottom of the docs that says you can't do that.  Is it feasible to destroy the host unit?
[01:32] <bradm> natefinch: no.
[01:32] <bradm> natefinch: the host unit is the juju state server
[01:34] <natefinch> bradm: not the host machine, the unit that the subordinate is attached to.  I don't know that it'll help, but it's possible
[01:35] <bradm> natefinch: oh, I see what you're saying. hmmm.
[01:35] <natefinch> thumper: any ideas? ^
[01:35] <bradm> natefinch: we don't have juju ha due to bug 1575448 so I need to be super careful
[01:35] <mup> Bug #1575448: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:New for anastasia-macmood> <https://launchpad.net/bugs/1575448>
[01:39] <natefinch> anastasiamac: are you looking that that one? ^
[01:39] <anastasiamac> natefinch: hang on, m reading backscroll
[01:40] <bradm> the jujuds are as flakey as anything, constant errors in it
[01:41] <anastasiamac> natefinch: it's with me but atm I need to reliably reproduce it. As part of this, m building vMAAS with 1.9... and m not there yet
[01:41] <anastasiamac> natefinch: do u want the bug?
[01:41] <natefinch> anastasiamac: no no no no no
[01:41] <anastasiamac> natefinch: and here i was holding my breath \o/
[01:42] <natefinch> anastasiamac: it's honestly probably nothing to do with maas, but I suppose you never know
[01:43] <anastasiamac> natefinch: yes, u may be right - our CI passes with maas and ha... but it does not help bradm ;)
[01:44] <anastasiamac> natefinch: and i still would like to have my own maas 1.9 :/
[01:44] <anastasiamac> natefinch: consider it my bday wish :D
[01:44] <natefinch> anastasiamac: I tried that at a sprint one, with the maas guys in the same room, still never got it working.  But that was a while ago, maybe it's better now
[01:44] <perrito666> anastasiamac: tap your heels 3 times and think on an orange box
[01:45] <natefinch> what we need is vmaas that rides on top of lxd... lxd generally Just Works
[01:45] <bradm> I just don't get what we're doing different to cause this much instability
[01:45] <anastasiamac> perrito666: it only works with red shoes and every time i try to go shoe shopping, wallyworld says i need to work :-P
[01:48] <natefinch> bradm: I wish I knew.
[01:50] <bradm> so the only suggestion is to destroy the parent service?
[01:51] <bradm> the only evidence I see of the subordinate is a directory /var/lib/juju/agents/unit-<service> with an agent.conf in it, but its not even fully filled out, when comparing it to others on the same node
[01:52] <anastasiamac> natefinch: i had a maas controller runnign yesterday, could not add nodes to it. today my machine keeps dying, i can;t reach maas controller anymore, m back to rebuilding it
[01:52] <perrito666> aghhhhh I need to test something in 1.25 and my environments.yaml is no more
[01:53] <anastasiamac> perrito666: what do u need? i can email u mine
[01:53] <perrito666> found a backup
[01:53] <perrito666> anastasiamac: I dont think you have my lxd conf :p
[01:54] <natefinch> bradm: I honestly have not dealt with subordinates hardly at all. Others might have more information.  wallyworld?
[01:54] <anastasiamac> perrito666: u r on ur own \o/ hope u swim well and r not afraid of heights
[01:54] <wallyworld> i've not used them much, other than to be under the impression their lifecycle is bound to the primary unit
[01:54] <anastasiamac> (or dark)
[01:59] <bradm> might spin up a test env and see what I can work out
[01:59] <bradm> I don't think destroying the service will help, since there appears to be no real trace of the subordinate on the problem node
[01:59] <bradm> as in, the subordinate service
[02:02] <davecheney> ahoy, anyone for a spot of team meeting ?
[02:02] <natefinch> davecheney: coming
[02:02] <menn0> thumper: coming?
[02:03] <natefinch> bradm: destroy/recreate *should help* I'd think, since a new subordinate should be created for the new unit
[02:03] <anastasiamac> natefinch: wallyworld:thumper: team meeting?
[02:03] <anastasiamac> axw: ping
[02:09] <rick_h_> wallyworld: hangout?
[02:09] <wallyworld> rick_h_: sure, give me a couple of mins? i'll ping you in a sec
[02:09] <rick_h_> k
[02:14] <wallyworld> rick_h_: https://hangouts.google.com/hangouts/_/canonical.com/ian-rick
[02:15] <rick_h_> wallyworld: can you invite me please?
[02:15] <wallyworld> ok
[02:15] <rick_h_> ty
[02:21] <cherylj> thumper, wallyworld can one of you find someone to take bug 1580802?
[02:21] <mup> Bug #1580802: NoContextWithLock fails on windows because of another process <blocker> <ci> <intermittent-failure> <regression> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1580802>
[02:22] <cherylj> anastasiamac, davecheney - are you guys okay with the week of june 13 for a sprint at that same hotel near brisbane?
[02:22] <cherylj> if so, I'll submit the sprint request
[02:23] <anastasiamac> cherylj: i am \o/
[02:24] <anastasiamac> cherylj: it was summer and nice to be by the oocean in December... m not sure it'd b just as great in June (winter here)
[02:26] <cherylj> oh ha, yeah, btw guys - -race is now run with the landing bot
[02:26] <cherylj> fun
[02:37] <natefinch> cherylj: awesome about -race
[02:38] <cherylj> not so much, looking at the last few runs
[02:45] <davecheney> cherylj: it has to be in sydney
[02:45] <davecheney> i've been travelling to much
[02:46] <davecheney> i'll be in the doghouse if I go away for another week
[02:46] <cherylj> anastasiamac: your thoughts on ^^?
[02:46] <anastasiamac> cherylj: sydney sounds good
[02:47] <cherylj> sydney it is, then
[02:48] <davecheney> 👍
[02:48] <thumper> coverage overhead on my machine, 18.5 minutes instead of 14.5 minutes
[02:48] <natefinch> thumper: that's not really all that bad
[02:49] <anastasiamac> thumper: and what is mean (or average) coverage that u r seeing?
[02:50] <thumper> I varies
[02:50] <anastasiamac> could u pastebin the output?
[02:50] <thumper> I've just closed up to go to a meeting off site, I'll let you know later
[02:50] <cherylj> is there someone who can take bug 1580802?
[02:50] <mup> Bug #1580802: NoContextWithLock fails on windows because of another process <blocker> <ci> <intermittent-failure> <regression> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1580802>
[02:51] <natefinch> cherylj: I just got my windows environment all set up, I could look at it in the morning
[02:52] <cherylj> is there someone who could take it now (in their daytime)?  I'm looking at you, Aussies and Kiwis :)
[02:53] <anastasiamac> cherylj: m not sure who in Aus and NZ has windows test environments...
[02:54] <cherylj> sinzui: are you still around to provide access to the windows machine?
[02:58] <perrito666> cherylj: if no one took it tomorrow AM I can also take it
[02:58] <perrito666> for the moment working on https://bugs.launchpad.net/juju-core/+bug/1577939
[02:58] <mup> Bug #1577939: Backup-restore failed on xenial because service "juju-db": No such file or directory <backup-restore> <blocker> <ci> <xenial> <juju-core:Incomplete> <juju-core 1.25:In Progress by hduran-8> <https://launchpad.net/bugs/1577939>
[02:59] <cherylj> thanks, perrito666
[03:01] <perrito666> k brain is failing, going to sleep, see you al tomorrow earlier than I would like
[03:02] <cherylj> ditto
[04:13] <thumper> anastasiamac: coverage from master http://pastebin.ubuntu.com/16372159/
[04:14] <thumper> wallyworld: any idea what is happening here: http://juju-ci.vapour.ws:8080/job/github-merge-juju/7709/console ?
[04:14] <wallyworld> waaaat
[04:15] <wallyworld> why did we have to turn on the race detector *now*
[04:15] <wallyworld> when we are trying to get a blessed build for beta7
[04:15] <wallyworld> surely it could have waited a couple of days
[04:15] <wallyworld> haven't seen those errors before
[04:16] <thumper> me neither
[04:16] <thumper> but it looks like they are trying to run with -race
[04:25] <davecheney>    wallyworld they should turn it off again
[04:26] <wallyworld> +1 from me
[04:26] <davecheney> or at least update the package with the fixes that michael landed recently
[04:26] <wallyworld> we weren't told it had happened till after the fact
[05:15] <axw> wallyworld: would you please take a look at https://github.com/juju/juju/pull/5383
[05:15] <axw> wallyworld: ignoring the first commit, which is already reviewed
[05:15] <wallyworld> sure
[05:15] <wallyworld> just give me 5
[05:15] <axw> wallyworld: no worries, take your time
[05:40] <wallyworld> axw: lgtm, thanks
[05:40] <wallyworld> good luck landing it though
[05:41] <axw> wallyworld: thanks. why's that?
[05:41] <wallyworld> axw: see backscroll abut race detector
[05:41] <axw> wallyworld: ah :/
[05:41] <wallyworld> it seems they need upstream fixes, plus our tests have races
[05:43] <axw> wallyworld: I've just had another look at your API doc, it looks good to me. I'm not sure if there is anything we need to change. probably just keeping the details like media types at the end as you've done is enough
[05:43] <wallyworld> axw: ta, yeah i'm hoping that's the case too
[05:44] <axw> wallyworld: also I do like the option of fetching all service details at once (with _embedded), but I wonder if that should be toggled with a query option?
[05:44] <bradm> so I did a juju add-unit to the state server, and a juju destroy-unit to the one with the failing subordinate, and it won't die, its still waiting for the failed subordinate to come up I think
[05:44] <wallyworld> axw: if you GET against the collection, you'll get a list of services matching any query params passed in. or am i misunderstanding
[05:45] <wallyworld> whereas GET against the service url itself returns just the one
[05:45] <axw> wallyworld: what are the query params? I don't see mention in the doc
[05:45] <axw> wallyworld: ah, further down
[05:45] <wallyworld> yeah
[05:46] <wallyworld> the top bit is just a summary
[05:46] <wallyworld> hides the gory details
[05:46] <wallyworld> bradm: not sure if --force is an option?
[05:46] <axw> wallyworld: so with the REST approach you'd just hit "/services", and traverse the _links right? but the response is also going to contain all the services in _embedded
[05:46] <bradm> wallyworld: nope, its not
[05:47] <bradm> wallyworld: at least, according to the help its not
[05:47] <wallyworld> axw: oh i see, we want a way to get *just* the links
[05:47] <axw> wallyworld: yeah I think so
[05:47] <bradm> wallyworld: yup, I get the "error: flag provided but not defined: --force" if I try
[05:48] <wallyworld> axw: yeah ok, we can do that, i might leave that off for now as i expect/hope we won't get that far. if i get time i'll add something
[05:48] <wallyworld> bradm: so do you know what's wrong with the subordinate?
[05:49] <bradm> wallyworld: it just didn't start up
[05:49] <bradm> wallyworld: the only evidence of it on the node is a partially filled out agent.conf
[05:50] <wallyworld> oh the agent didn't come up
[05:50] <bradm> "Waiting for agent initialization to finish" is the message
[05:50] <wallyworld> i have no idea how to beat a subordinate unit into submission
[05:50] <bradm> time for another bug then, I guess
[05:50] <wallyworld> i fear it may require a db hack and an agent restart
[05:51] <bradm> ugh
[05:51] <bradm> this is about to go live too, its one of the things holding it up
[05:51] <wallyworld> but that's just me, there may be a better answer
[05:51] <wallyworld> william would be a good person to ask
[05:52] <wallyworld> a post to juju-dev mailing list would be good
[05:56] <bradm> juju-dev@lists.u.c ?
[06:20] <jam> axw: interesting. I would have thought each API request would be a separate span. rather than each connection (given agents stay connected for days)
[06:20] <jam> and then you'd just tag the spans with the username that is connected.
[06:20] <axw> jam: yeah, I think each request would be better (after looking at the results)
[06:20] <jam> and then you definitely want to start breaking down spans so that you can do things like how long the DB request took, etc.
[06:20] <axw> jam: it would be sometimes helpful to have a span per connection, e.g. for user connections
[06:21] <axw> i.e. user commands making multiple API requests
[06:21] <jam> axw: it sounds like zipkin/whatever is going to be reasonably similar, probably much flashier with represntation and ability to dig into it.
[06:21] <axw> jam: yes, I think so
[06:26] <bradm> wallyworld: email away to juju-dev, hopefully someone knows how to fix it
[09:02] <voidspace> dooferlad: standup?
[09:06] <dooferlad> voidspace: for some reason my mic and camera won't work today. Great.
[09:06] <voidspace> dooferlad: ok dude
[09:13] <voidspace> dooferlad: dimitern: frobware: firefox crash - will have to rejoin
[09:13] <voidspace> dooferlad: oops, not you
[09:13] <dooferlad> voidspace: :-)
[09:14] <voidspace> dooferlad: ah, you are there
[09:14] <voidspace> dooferlad: o/
[09:14] <dooferlad> voidspace: I rebooted
[09:14] <dooferlad> :-)
[09:14] <voidspace> the classic fix...
[09:29] <voidspace> dimitern: I have the email suggesting "ID := <model-uuid>:<global-key>"
[09:29] <voidspace> e.g. "uuid:space#foo" (for a space provider ID)
[09:29] <voidspace> dimitern: so I'll do that
[09:29] <voidspace> dimitern: may ping you about it later
[09:31] <dimitern> voidspace: just forwarded the last thing I sent on that thread
[09:31] <dimitern> voidspace: sounds good, thanks!
[09:31] <voidspace> dimitern: kk
[09:47] <mup> Bug #1580946 opened: Juju 2 help commands for constraints or  placement return ERROR unknown command <juju-core:New> <https://launchpad.net/bugs/1580946>
[10:36] <dooferlad> dimitern: FYI I am writing some stuff for thumper to give him some context about networks. If you could start on the state of Juju and what we can combine our efforts later.
[10:37] <dooferlad> ...Juju and what we have tried... that is
[10:37] <dimitern> dooferlad: ok, I'll look into it later today
[10:59] <mup> Bug #1580964 opened: LXD network container profiles need not be discrete entries <juju-core:New> <https://launchpad.net/bugs/1580964>
[11:08] <dimitern> axw, menn0: hey, is anyone of you around by chance?
[11:36]  * dimitern wish in addition to restricted, there were auto-inherited-from-controller model attributes
[13:16] <sinzui> wallyworld: thumper-afk: I removed the --race from the lander and your branches are requeued
[13:16] <wallyworld> yay, tyvm
[13:16] <sinzui> ^ alexisb
[13:17] <alexisb> thank you sinzui!
[14:33] <mup> Bug #1581069 opened: controller leaking mongodb connections <juju-core:New> <https://launchpad.net/bugs/1581069>
[14:36] <dooferlad> jam: do we have a cloud feature / juju feature matrix that you know of? Is that something you could help put together?
[14:37] <dooferlad> jam: thumper was asking for it as well as some networking background. I am handling the networking background at the moment...
[14:45] <mup> Bug #1581069 changed: controller leaking mongodb connections <juju-core:New> <https://launchpad.net/bugs/1581069>
[14:48] <rick_h_> jcastro: ping got a sec?
[14:50] <jcastro> rick_h_: shoot
[14:50] <rick_h_> jcastro: you played with the add-user in 2.0? and registering/etc?
[14:50] <jcastro> I have not yet, no
[14:51] <rick_h_> jcastro: so I'm setting it up for a demo and just tried it out and was awesome to email a command to myself, go to another machine, paste it, and then run juju-gui to have access to a subset of the controller
[14:51] <rick_h_> jcastro: I've got a school event in the AM tomorrow, but curious if you'd have time to incldue that in the office hours?
[14:51] <jcastro> oooh, we have office hours this week
[14:51] <jcastro> yeah
[14:51] <jcastro> I'll work it in somehow
[14:51] <rick_h_> jcastro: or someone else there
[14:51] <rick_h_> I'll sent you notes/etc if you want before EOD, but this is cool/worth sharing imo
[14:52]  * rick_h_ volunteered to make school popcorn day 
[14:55]  * perrito666 has pavlovian conditioning that onlly allows him to eat popcorn while watching movies
[14:57] <mup> Bug #1581069 opened: controller leaking mongodb connections <juju-core:New> <https://launchpad.net/bugs/1581069>
[15:03] <mup> Bug #1581074 opened: LXD container interface names don't align with parent interface names <lxd> <network> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1581074>
[15:05] <katco> ericsnow: standup time
[15:12] <natefinch> redir: http://dave.cheney.net/2013/06/19/stress-test-your-go-packages
[15:13] <perrito666> natefinch: dave gave him the link last night
[15:16] <katco> perrito666: hey would you mind joining moonstone rq? https://hangouts.google.com/hangouts/_/canonical.com/moonstone?authuser=1
[15:16] <perrito666> katco: sure, gimme a sec
[15:35] <voidspace> dimitern|away: is it true legacyipaddressesC is used for "address allocation" on aws?
[15:40] <natefinch> alexisb, cherylj: bug https://bugs.launchpad.net/juju-core/+bug/1580802 was diagnosed by davecheney as yet another fslock bug. Fixing it should probably involve not using file locks on windows, given that there's a syscall specifically for application-wide locks like this (CreateMutex).  It's not a huge lift, but it's not a minor bugfix either.  Not sure what you want to do.
[15:40] <mup> Bug #1580802: NoContextWithLock fails on windows because of another process <blocker> <ci> <intermittent-failure> <regression> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1580802>
[15:40] <alexisb> natefinch, otp one sec
[16:10] <cherylj> katco: ping?
[16:10] <katco> cherylj: otp, what's up?
[16:11] <cherylj> katco: just coming up for air from my meetings, wanted to follow up on providing that binary
[16:11] <katco> cherylj: other channel?
[16:17] <alexisb> ok natefinch sorry reading back
[16:17] <alexisb> natefinch, we agree
[16:18] <alexisb> we need to fix that but the fslock issue is more then what is doable in beta timeframe
[16:42] <natefinch> alexisb: ok, looking into what we can do in a limited time frame.
[16:45] <perrito666> anyone have time for a quick review? http://reviews.vapour.ws/r/4817/diff/#
[16:46] <natefinch> perrito666: tests?
[17:04] <mup> Bug #1568895 changed: Cannot add MAAS-based LXD containers in 2.0beta4 on trusty <ci> <jujuqa> <lxd> <maas-provider> <cloud-images:Fix Released> <juju-core:Fix Released> <https://launchpad.net/bugs/1568895>
[17:04] <mup> Bug #1581138 opened: Juju20: websockets API unhelpful error message when not specifying support facade Version parameter <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1581138>
[17:04] <mgz> cherylj, sinzui: updated the cloud-images and ran some tests, both centos with new tls and trusty with backports verified working
[17:04] <mgz> cherylj, sinzui: feel like I'm forgetting something else thouhg?
[17:05] <natefinch> you know your lock object is buggy when it needs a BreakLock method :/
[17:05] <sinzui> mgz: I don't think you are. the windows jobs are a separate issue
[17:06] <natefinch> mgz: huzzah about centos :)
[17:06] <sinzui> mgz: and we are also testing centos in aws
[17:06] <cory_fu> I have a question in #juju regarding "chaining" subordinates that I think I might need a core dev to answer
[17:06] <cory_fu> If someone has a moment
[17:07] <sinzui> mgz: cherylj I have hacked the registry of the windows host. I am replaying the win tests, I am not certain go the keys/items right.
[17:07] <mgz> sinzui: bogdanteleaga reckons the real problem is the tests actually building/using jujud
[17:08] <natefinch> cory_fu: we can try... but most of us aren't too familiar with subordinates. And chaining them sounds like dangerous waters.
[17:08] <mgz> cory_fu: I'm pretty sure the answer is just "that doesn't work"
[17:08] <mgz> but you can have a subordinate that only operates if it has a sibling subordinate
[17:08] <mgz> seems like kind of a bad thing, but hey
[17:09] <cory_fu> I don't see why it shouldn't.  There's a princpal at some level, and the relationship I actually want to model is between the two subordinates
[17:10] <cory_fu> In my case, the plugin wants to provide Hadoop, but it requires Java to do so.  And Java is provided by another subordinate, but it's providing that to the plugin, not the principal
[17:10] <sinzui> mgz yeah. I used the powershell script from windows_userdata_test.go as my guide.
[17:11] <mgz> cory_fu: what your operating is probably doing in practice is saying if there's a new service named the same as your existing subordinate, then deploy the sub-subordinate along with it
[17:11] <mgz> which isn't what you mean at all
[17:11] <mgz> -ing +ion
[17:12] <katco> natefinch: where is your fix for destroy environment landed?
[17:12] <natefinch> katco: no where, because 1.25 us blocked, and this was not a blocking bug
[17:13] <katco> natefinch: k
[17:13] <natefinch> katco:  here's the PR: https://github.com/juju/juju/pull/5363
[17:13] <mup> Bug #1581138 changed: Juju20: websockets API unhelpful error message when not specifying support facade Version parameter <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1581138>
[17:13] <mup> Bug #1568895 opened: Cannot add MAAS-based LXD containers in 2.0beta4 on trusty <ci> <jujuqa> <lxd> <maas-provider> <cloud-images:Fix Released> <juju-core:Fix Released> <https://launchpad.net/bugs/1568895>
[17:13] <katco> natefinch: ty
[17:13] <mgz> cory_fu: I'm unconviced by doing dependency management through subordiante charms. I'd probably just make the plugin include the existing logic for getting java installed, and have that as a module charms could pick up and use.
[17:13] <cory_fu> mgz: I don't understand that at all, but it sounds like an implementation detail.  From my point of view, I'm trying to model the relationships between the components, and the relationship I care about is between the openjdk subordinate and the Hadoop plugin subordinate, and I don't see why I shouldn't be able to do that.
[17:14] <natefinch> cory_fu: why doesn't the hadoop subordinate include openjdk directly?
[17:15] <perrito666> sinzui: https://bugs.launchpad.net/juju-core/+bug/1575469 only affects 1.25?
[17:15] <mup> Bug #1575469: liveSuite.TestBootstrapMultiple invalid character \"\\\\\" in host name <blocker> <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1575469>
[17:15] <cory_fu> Yeah, I suppose that's an argument.  The value we saw in doing it this way is that we have several vendors that want to provide different Javas (IBM, Zulu8, etc) and we don't want to force every charm to build against every vendor's Java since it's more of a deploy-time concern which would work best (depends on hardware, etc)
[17:15] <sinzui> perrito666: yes
[17:15] <perrito666> odd
[17:15] <natefinch> cory_fu: in 2.0 that would be a function for resources
[17:16] <mgz> cory_fu: was saying why I think it doesn't work. I think adding a subordinate assumes one principle and one subordinate
[17:16] <mgz> cory_fu: I think there's a worthwhile larger discussion about the best way of structuring this stuff
[17:16] <perrito666> k taken, thanks sinzui
[17:16] <mgz> but I expect the current bug is more than juju doesn't tell you that doesn't work, rather than it not working.
[17:16] <cory_fu> mgz: Fair enough.  :)
[17:17] <mgz> still worth a bug though!
[17:17] <natefinch> cory_fu: I presume you're not using 2.0 :)
[17:17] <sinzui> perrito666: I think master got a fix on april 26/27 because master started passing on 27 http://reports.vapour.ws/releases/issue/5720374a749a561a8c7390ac
[17:17] <perrito666> yup, I fixed those, I fear the fix is in utils, which is harder to update in older juju
[17:18] <cory_fu> natefinch: The java interface / charms were started a while ago, before resources were started.  Resources do seem like a reasonable way to handle this, though it still means that vendors can only provide a blob and not necessarily charm logic around it (though I guess they could put an installer in the blob)
[17:25] <mup> Bug #1568895 changed: Cannot add MAAS-based LXD containers in 2.0beta4 on trusty <ci> <jujuqa> <lxd> <maas-provider> <cloud-images:Fix Released> <juju-core:Fix Released> <https://launchpad.net/bugs/1568895>
[17:25] <mup> Bug #1581138 opened: Juju20: websockets API unhelpful error message when not specifying support facade Version parameter <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1581138>
[17:30] <natefinch> cory_fu: I'm sure you could figure out a way to combine resources with some config to do what you needed... but yeah, I understand that resources aren't even in a release version of Juju yet
[17:35] <katco> natefinch: can you verify your destroy-environment fix by compiling/running this branch? https://github.com/juju/juju/tree/1.25.3-and-fixes
[17:35] <katco> natefinch: top priority
[17:36] <cory_fu> natefinch: Yeah.  There's also the issue that using resources drastically reduces the discoverability for vendors wanting to promote their Java, as well as makes it really unclear how to handle ownership (unless my understanding of the association of resources with specific charms is terribly out of date)
[17:38] <cory_fu> IBM and Azul Zulu were both really happy that they could get their Java offerings to show up in the store with an easy way for any charm to choose (and change) which one they use
[17:39] <ericsnow> redir: FYI, PR #5385 has a 0-length diff
[17:39] <mgz> sounds like a very efficient change
[17:39] <natefinch> ka sure
[17:39] <ericsnow> :)
[17:39] <natefinch> katco: sure
[17:40] <katco> natefinch: ta
[17:42] <redir_> ericsnow: tx :|
[17:42] <redir_> git ate my homework
[17:45] <natefinch> cory_fu: yeah, promoting and ownership of resources was not really one of the use cases we were aware of.  Maybe in v2 of resources, if we do such a thing, that could be worked in.  The subordinate of a subordinate thing is kind of adding an edge case on top of an edge case, though.
[17:45] <cory_fu> Agreed.  It's not something we'd encountered or even considered before, either.
[17:55] <mup> Bug #1576313 opened: windows: uniter tests fail because logs get dumped to stderr <blocker> <ci> <regression> <test-failure> <windows> <juju-ci-tools:Triaged> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1576313>
[17:57] <natefinch> tests that read logs and/or stderr (without very controlled context) should be shot in the head
[17:59] <perrito666> natefinch: actually that one is entirely our fault
[17:59] <perrito666> at some point we run jujud
[17:59] <perrito666> and windows does not redirect that  stderr very nicely
[17:59] <perrito666> yes, you read that right, we run jujud :p
[17:59] <natefinch> list of things your unit tests should never do: run a copy of the executable built from the code under test
[18:00] <natefinch> perrito666: oh I know
[18:00] <perrito666> there is a nice comment from fwereade on what he thinks about that :p
[18:00] <perrito666> just above the relevant code
[18:02] <natefinch> yep
[18:02] <natefinch> katco: the code checks out
[18:03] <natefinch> katco: at least, the manual test that was very reliably reproducing the problem passes
[18:03] <katco> natefinch: yay :) ty
[18:07] <perrito666> gtg for a while, bbl
[18:18] <ahasenack> tvansteenburgh: hi, the builds aren't looking pretty, I can't debug that now
[18:18] <ahasenack> https://code.launchpad.net/~ahasenack/+recipe/juju-deployer-daily
[18:19] <tvansteenburgh> ahasenack: looking
[18:20] <tvansteenburgh> ahasenack: bah, i forgot about the test deps, will file another MP
[18:20] <ahasenack> tvansteenburgh: thx, I suspected it tried to use pip to install what was missing
[18:22] <tvansteenburgh> ahasenack: yeah it does, but they have to be already installed by build-depends right?
[18:22] <ahasenack> right
[18:22] <ahasenack> secpolicy doesn't allow that
[18:22] <tvansteenburgh> ahasenack: ok
[18:25] <mup> Bug #1581157 opened: github.com/juju/juju/cmd/jujud test timeout on widnows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1581157>
[18:36] <redir_> natefinch: got a minute to look at something?
[18:36] <natefinch> redir_: sure
[18:36] <redir_> moonstone?
[18:36] <redir_> natefinch: ^
[18:36] <natefinch> yep
[19:11] <bdx> hey whats up everyone?
[19:11] <bdx> where is the templating for network inetrfaces for the maas provider?
[19:12] <bdx> we need 'auto <iface>' add to the network interface templates
[19:12] <bdx> currently my interfaces get created, but I have to manually 'sudo ifup <iface>' post deploy on maas nodes
[19:13] <bdx> deployed with juju
[19:15] <bdx> https://github.com/juju/juju/issues/5386
[19:23] <katco> natefinch: apologies, can you test your manual fix again? i missed up the merge on ian's fix and had to recreate
[19:24] <katco> natefinch: manual test rather
[19:27] <natefinch> katco: sure. no problem
[19:34] <natefinch> katco: looks fine
[19:34] <katco> natefinch: ta
[19:43] <mup> Bug #1581190 opened: juju 2.0: debug-log --include machine-X includes more data than just machine-x <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1581190>
[19:52] <mup> Bug #1581190 changed: juju 2.0: debug-log --include machine-X includes more data than just machine-x <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1581190>
[19:55] <mup> Bug #1581190 opened: juju 2.0: debug-log --include machine-X includes more data than just machine-x <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1581190>
[20:24] <alexisb> bdx, the guys that have the best insight on that q are currently sleeping
[20:25] <alexisb> bdx, but I can get eyes on the issue when they are back online tomorrow, if someone currently on doesnt have a chance to dig
[21:07] <perrito666> man I could learn to knit while waiting tests in windows to pass
[21:07] <katco> perrito666: could leave out the word windows there
[21:08] <perrito666> katco: well, I presume it is because its because its a vm, but they are slower than when running native
[21:29] <mup> Bug #1581211 opened: [Juju/MAAS 2.0] Juju doesn't show correct error when MAAS doesn't have required images. <juju-core:New> <https://launchpad.net/bugs/1581211>
[21:43]  * perrito666 headbuts the keyboard waiting for the second run
[22:00] <perrito666> wallyworld: coming?
[23:04] <bradm> anyone have any ideas on my broken subordinate problem?  emailed juju-dev list about it last night
[23:38] <axw> redir: what did you want me to look at?