[00:07] <wallyworld> veebers: i just hacked up something in code as a temp thing on my system
[00:07] <redir> wallyworld: got any availability in the next 60-90m?
[00:07] <wallyworld> redir: sure
[00:07] <redir> wallyworld: pick a time any time
[00:07] <wallyworld> redir: now is good,that way you can escape and go do dinner or whatever
[00:07] <redir> k
[00:08] <redir> tanzanite?
[00:08] <wallyworld> ok
[00:29] <menn0> thumper: here's the fix for the debug-log sorting issue: http://reviews.vapour.ws/r/5229/
[00:29] <thumper> menn0: kk, will look shortly
[01:01] <thumper> menn0: http://reviews.vapour.ws/r/5230/
[01:05] <menn0> thumper: will take a look in a sec
[01:06] <menn0> thumper, wallyworld: I can't land the fix for 1590605 b/c it isn't a blocker
[01:06] <thumper> menn0: JFDI
[01:06] <wallyworld> +1
[01:06] <menn0> ok
[01:32] <rick_h_> wallyworld: hacked up the ACL spec based on conversations I had with jam and urulama today
[01:32] <rick_h_> wallyworld: PTAL sometime and let me know if that's ok by you and any issues/concerns from here
[01:33] <wallyworld> rick_h_: will do, in meeting, will look straight after, ty
[01:33] <rick_h_> wallyworld: all good, thanks for giving it a go when you're free
[01:58] <mup> Bug #1602010 changed: juju status doens't display proper error when machine fails <juju-core:New> <https://launchpad.net/bugs/1602010>
[01:59] <veebers> wallyworld: everytime I enable log forwarding (and it works i.e. I use the right host IP) it triggers that logging bug (#1599779)
[01:59] <mup> Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1599779>
[01:59] <veebers> wallyworld: is there any useful information that I can provide you? I doubt I'm doing anything special or out of the ordinary
[02:00] <wallyworld> veebers: i think i have enough now - i am rewriting some stuff, i will have something fixed today
[02:00] <veebers> wallyworld: ah cool :-)
[02:00] <wallyworld> veebers: but apart from that, good that it works, thanks for testing
[02:02] <wallyworld> rick_h_: one thing, thumper said that mark himself was the one who originally wanted the add-user command to include the --shared models option, so you will need to be sure that he is across the change to remove that
[02:35] <axw> wallyworld: FYI I found that state was still allowing controller config into model config in some cases (I think only in tests), so currently fixing a bunch more things.
[02:36] <wallyworld> ok
[02:51] <axw> thumper menn0: was environs.MigrationConfigUpdater added only for azure? the need for it has gone away, so I'll remove it unless there's another use case
[02:51] <thumper> not sure TBH
[02:52] <axw> (we don't have controller-uuid in model config anymore. we'll need a way to retag things, but should be done a bit differently I think)
[02:52] <axw> thumper: it's not implemented by anything other than dummy, so I'll remove it and we can reinstate if needed
[02:58] <mup> Bug #1556153 changed: ERROR destroying instances: cannot release nodes: gomaasapi: got error back from server: 504 GATEWAY TIMEOUT (Unexpected exception: TimeoutError <oil> <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1556153>
[03:01] <mup> Bug #1556153 opened: ERROR destroying instances: cannot release nodes: gomaasapi: got error back from server: 504 GATEWAY TIMEOUT (Unexpected exception: TimeoutError <oil> <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1556153>
[03:07] <mup> Bug #1556153 changed: ERROR destroying instances: cannot release nodes: gomaasapi: got error back from server: 504 GATEWAY TIMEOUT (Unexpected exception: TimeoutError <oil> <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1556153>
[03:08] <menn0> thumper: ship it for 5230
[03:08] <menn0> wallyworld: chat?
[03:08] <thumper> menn0: cheers
[03:09] <wallyworld> menn0: sure, https://hangouts.google.com/hangouts/_/canonical.com/tanzanite-stand
[03:09] <wallyworld> axw: you canpop in too if you're free - talk about log streamer etc
[03:47] <axw> wallyworld: can you PTAL at ahttp://reviews.vapour.ws/r/5224/, just the last commit/rev. I've remove ca-private-key from controller config attrs, plugged a hole in state where we allowed controller config through, and fixed fallout
[03:47] <axw> wallyworld: there was a bit of model migration removed too, which was added for azure but is no longer needed
[03:47] <wallyworld> ok
[03:53] <wallyworld> axw: minor typo. so the private key should just go to state serving info (from memory) and nowhere else
[03:54] <wallyworld> it is used by the cert update worker
[03:54] <axw> wallyworld: thanks. yes, that is correct
[03:55] <wallyworld> so godd that it is also removed from controller config as nothing else needs to see it
[03:55] <wallyworld> good
[05:02] <mup> Bug #1602508 opened: LastLogTracker accesses mongo collections directly <2.0> <juju-core:Triaged> <https://launchpad.net/bugs/1602508>
[05:29] <wallyworld> axw: when you have time, here's that log forward fix http://reviews.vapour.ws/r/5231/
[05:41] <axw> wallyworld: reviewed
[05:41] <wallyworld> ta
[05:43] <axw> argh, juju-ci is Service Unavailable
[05:44] <wallyworld> axw: i didn't want to make any assumptions about order - i guess i could pick the one with the biggest timestamp
[05:44] <axw> wallyworld: well we forward them in order don't we?
[05:44] <axw> I'm pretty sure that's part of the contract
[05:45] <wallyworld> fair enough, i was being overly cautious i guess
[05:52] <wallyworld> axw: fixed
[05:54] <axw> wallyworld: LGTM, thanks
[05:54] <wallyworld> ta
[05:54] <axw> wallyworld: CI is buggered atm
[05:54] <wallyworld> oh, damn
[05:54] <axw> seems the jenkins agent died, I don't know how to fix it tho
[05:54] <wallyworld> axw: same thing happended yesterday too
[05:55] <axw> interesting
[05:58] <axw> jam: it was changed from SetList to SetLastSent
[06:11] <jam> axw: ah, just read it backwards then.
[06:11] <jam> thanks
[06:47] <wallyworld> axw: the juju login command - where does that write to the db? ie the macaroon and record of login
[06:54] <axw> wallyworld: it requests a macaroon from the controller, the controller generates a root key for the macaroon. that's the only thing that's stored in the db
[06:54] <axw> wallyworld: otherwise it's all stored client side
[06:55] <wallyworld> axw: np, thanks. i'm commenting on https://docs.google.com/document/d/1xRO2tbeC-Dg5JdSV-wMYIZQel11EfWqPk8LU-0XdH8Y
[06:57] <axw> wallyworld: when you send the LoginRequest, you can optionally include a model UUID. if you don't include it, you get a controller-only login. so that much already exists, if I'm interpreting it correctly
[06:57] <wallyworld> axw: yep, that's what i though too
[06:58] <axw> wallyworld: do you recall why you made this change? https://github.com/juju/juju/commit/f751ea7b54876a5a38dbef6dfc90e1d56b1531d5
[06:59] <axw> wallyworld: I'm trying to weed out unnecessary environs.Environ constructions, this code stuck out as a bit odd
[07:00] <wallyworld> axw: not 100% sure - i think the intent was to not do an upgrade (or attempt it) if there was an issue with the cloud and the machines could not be contacted
[07:00] <wallyworld> so a sanity / pre-upgrade check
[07:00] <axw> hm, ok.
[07:02] <wallyworld> axw: i can't recall where the requirement came from, but i recall "someone" asked for it
[07:02] <axw> wallyworld: alright. I'll leave it alone
[07:19] <wallyworld> axw:  can you join us? https://hangouts.google.com/hangouts/_/canonical.com/regular-catchup
[07:20] <axw> wallyworld: be there in a moment
[07:34] <jam> frobware: ping
[07:55] <rogpeppe2> axw: hiya
[07:55] <axw> rogpeppe2: hey
[07:56] <axw> rogpeppe: I'm hopping on a call shortly, but will be around after that (in an hour or so)
[07:56] <rogpeppe> axw: ok, cool
[07:56] <rogpeppe> axw: let's do it then
[07:56] <axw> rogpeppe: I just did a little test, if you set the value of "user" in accounts.yaml to nothing, and remove the password line, it should trigger external auth
[07:56] <axw> rogpeppe: except there's a bug, fixed by http://reviews.vapour.ws/r/5232/
[07:57] <rogpeppe> axw: ah yes, i came across that
[07:57] <rogpeppe> axw: it's still not ideal though
[07:57] <axw> rogpeppe: re your email, I think we could more or less drop accounts.yaml, we just need the logged-in user's details. we used to support multiple users logged in simulataneously from the same client, but not now
[07:58] <axw> so models.yaml shouldn't need the account qualifier. they would implicitly be relative to the logged-in user
[07:59] <rogpeppe> axw: ah, ok - i guess that the jujuclient API is already due for an update then
[07:59] <axw> rogpeppe: it wasn't really necessary until now, but I do think this tips it over the edge
[08:00] <rogpeppe> axw: wouldn't you still need accounts.yaml 'cos you can still have a different user for each controller?
[08:01] <axw> rogpeppe: yeah, sorry, we can't drop that - we can only drop the account part from models.yaml
[08:01] <jam> axw: tech board?
[08:01] <axw> rogpeppe: accounts.yaml would just become controller -> {user creds}
[08:01] <axw> jam: coming
[08:01] <rogpeppe> axw: right, cool
[08:01] <rogpeppe> axw: as i think i suggested in my email
[08:30] <rogpeppe> axw: just looking at http://reviews.vapour.ws/r/5205/diff/# - doesn't our suggested approach above rather go against what that's doing?
[08:38] <mup> Bug #1602572 opened: Handler function is not being called even after changed one of the config values of the config.yaml <juju-core:New> <https://launchpad.net/bugs/1602572>
[09:02] <thumper> night all
[09:03] <axw> rogpeppe: back. looking...
[09:05] <axw> rogpeppe: suggested approach of changes to accounts.yaml?
[09:05] <rogpeppe> axw: well, of changes to models.yaml really
[09:06] <rogpeppe> axw: if a model isn't relative to an account, then it's not going to be that easy to namespace model names by user
[09:06] <axw> rogpeppe: models.yaml will only store information about models that the logged in user has access to. and you can still tell what user you're logged in as
[09:07] <axw> rogpeppe: I think the only thing that changes in that diff is to replace the use of AccountName with the logged-in user name
[09:07] <axw> which we get back from login
[09:10] <rogpeppe> axw: i guess i'm wondering whether the model namespace is actually still per-user
[09:10] <rogpeppe> axw: have you got some time to pair for a bit?
[09:10] <axw> rogpeppe: yes
[09:14] <mup> Bug #1602591 opened: Juju 2.0 Resources: Issue while fetching empty resources from charm store <juju-core:New> <https://launchpad.net/bugs/1602591>
[10:20] <mup> Bug #1602591 changed: Juju 2.0 Resources: Issue while fetching empty resources from charm store <juju-core:New> <https://launchpad.net/bugs/1602591>
[10:20] <mup> Bug #1584616 opened: mtu configuration should not be moved to bridge interface <network> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1584616>
[10:21] <axw> mgz: are you around? do you know juju-ci is busted?
[10:47] <frobware> dooferlad: ping - do you some time to look over my sholder at some networky things....
[10:47] <dooferlad> frobware: sure
[10:48] <frobware> dooferlad: 1:1 HO
[11:09] <axw> rogpeppe: https://github.com/juju/juju/pull/5788
[11:39] <perrito666> morning all
[12:14] <axw> rogpeppe: back for 10 mins or so - how's it going?
[12:18] <mgz> axw: yeah, it's I think just the proxy server, master seems to be up and doing things
[12:19] <axw> mgz: when I ssh'd to the machine, the jenkins job log said the agent had terminated or something like that
[12:23] <mgz> have restarted jenkins to see if it get stuck in the same loop
[12:25] <mgz> axw: well, it's up now, possibly still not very happy?
[12:25] <axw> mgz: I'll try landing my branch again, we'll see :)
[12:25] <axw> mgz: thanks
[13:26] <rogpeppe> axw: sorry, was on lunch
[14:03] <cherylj> mgz: got a few to help me look at the 1.25 CI failures?
[14:04] <babbageclunk> Help - does anyone know about how cloud-init works?
[14:04] <mgz> cherylj: sure, daily hangout?
[14:05] <cherylj> mgz: yeah, omw
[14:05] <cherylj> babbageclunk: you may have some luck asking in #cloudware on the canonical IRC
[14:06] <babbageclunk> Ok, thanks - I pinged smoser but caught him on the way out.
[14:22] <frobware> anybody see this "bad ports from GCE: invalid port range 0-0/tcp" from GCE recently?
[14:45] <mup> Bug #1602716 opened: MAAS provider bridge script doesn't handle alias interfaces IP <maas-provider> <network> <sts> <juju-core:New> <https://launchpad.net/bugs/1602716>
[14:59] <lazyPower> frobware - i have not, i've been running nearly exclusively on GCE since beta-8
[14:59] <lazyPower> frobware - any clue on reproduction? I'm happy to give it a go
[15:06] <perrito666> controlleruuid and controllermodeluuid are the same always? and if so, is that by design?
[15:09] <alexisb_> frobware, looks like a bug just got opened
[15:15] <mup> Bug #1602732 opened: GCE bad ports 0-0/tcp <blocker> <ci> <gce> <regression> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1602732>
[15:16] <cherylj> lazyPower, frobware just be aware that that bug also leaves the controller instance alive.
[15:16] <cherylj> yay!
[15:16] <cherylj> mgz: ^^  fyi
[15:16] <cherylj> perrito666: yes, that is by design
[15:17] <cherylj> babbageclunk: have you been able to get help with your cloud-init question?
[15:17]  * perrito666 decides not to create a controllerTag
[15:17] <cherylj> perrito666: that being said, I don't know if there are plans to change that
[15:18] <babbageclunk> cherylj: yes, some - I'll do an update on the bug.
[15:18] <perrito666> cherylj: ah, that was my next question
[15:18] <mup> Bug #1602732 changed: GCE bad ports 0-0/tcp <blocker> <ci> <gce> <regression> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1602732>
[15:18] <alexisb_> babbageclunk, should this bug be fix committed: https://bugs.launchpad.net/juju-core/+bug/1598897 ??
[15:18] <mup> Bug #1598897: juju status: relation name oscillates for peer relations <juju-core:In Progress by 2-xtian> <https://launchpad.net/bugs/1598897>
[15:18] <alexisb_> if so I will update it for you
[15:19] <cherylj> alexisb_: just fyi - that GCE bug means that no one can bootstrap on GCE now with the current master
[15:19] <babbageclunk> alexisb_: oops, yes please.
[15:19] <alexisb_> cherylj, yes
[15:19]  * cherylj sadface
[15:19] <alexisb_> it will need to get fixed before we release
[15:19] <cherylj> heh
[15:21] <mup> Bug #1602732 opened: GCE bad ports 0-0/tcp <blocker> <ci> <gce> <regression> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1602732>
[15:21] <lazyPower> ah ok, i'm currently on beta-11
[15:22] <lazyPower> that makes sense why i haven't seen it if its only affecting master
[15:23] <cherylj> lazyPower: yeah, just injected yesterday
[15:36] <natefinch> gah, who decided that github.com/juju/juju/cloud.Cloud shouldn't have a Name field :/
[15:38] <natefinch> one might assume the name of a cloud might be important info :/
[15:43] <perrito666> oh, great, another breaking change, people is going ot hate me
[15:44] <alexisb_> perrito666, what change?
[15:44] <perrito666> alexisb_: oh, not that breaking
[15:44] <frobware> mgz: thanks for raising the bug
[15:45] <perrito666> alexisb_: I am writing controller permissions and thinking on unifying some code but on second thought it might be better to have a bit of code duplication at this point
[15:45] <frobware> lazyPower: yep, fails on tip (plus my changes, which don't seem to make it worse/better)
[15:51] <mup> Bug #1602749 opened: no visible sign that HA is degraded when lost  <2.0> <usability> <juju-core:Confirmed> <https://launchpad.net/bugs/1602749>
[15:52] <natefinch> searching for the string literal "lxd" returns a distressing number of hits.  did we not all have it beaten into our heads to always use constants and not write out string literals everywhere?
[15:54] <katco`> cherylj: any objections to raising bug 1598063 as critical so i can land the fix?
[15:54] <mup> Bug #1598063: Data race in apiserver/observer package <ci> <race-condition> <juju-core:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1598063>
[15:54] <cherylj> katco:  no objections :)
[15:54] <katco`> cherylj: great, thx!
[15:55] <cherylj> you'll need to add the blocker tag too to use the $$fixes-####$$ notation
[15:55] <katco`> cherylj: ah ok
[15:57] <frobware> dooferlad: thanks for the link to the alias bug
[15:59] <dooferlad> frobware: I assume that is sarcasm...
[15:59] <frobware> dooferlad: check!
[15:59] <frobware> sigh
[16:00] <frobware> dooferlad: we used to bridge aliases but removed it. I cannot immediately recally why we removed bridges for aliases...
[16:03] <natefinch> oh man, we love spooky action at a distance in this codebase
[16:04] <dooferlad> frobware: I am hoping that https://bugs.launchpad.net/juju-core/+bug/1602054 is related to some interfaces juggling, but I am not seeing much hope.
[16:04] <mup> Bug #1602054: juju deployed lxd containers are missing a default gateway when configured with multiple interfaces <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1602054>
[16:05] <frobware> dooferlad: you wrote "we save the original in /etc/network" - we do?
[16:05] <dooferlad> frobware: unfortunately when trying to recreate the issue I set up two NICs on the MAAS controller, put the new NIC on another subnet and then I couldn't add a LXD because Juju was trying to connect to the wrong IP address. Yay.
[16:06]  * dooferlad goes to make dinner and ponder the wrongs of trying to make computers communicate
[16:06] <frobware> dooferlad: have you tried putting both on the same subnet?
[16:07] <frobware> cherylj, mgz: not that I have cloud-city creds for GCE, is there a way to get to the dashboard to kill of my rogue instance. Up until recently I was using my own (free/trial) account.
[16:08] <mgz> frobware: I can add you if you promise to be good
[16:09] <frobware> mgz: I can be good-ish. Promise-ish. :)
[16:09] <cherylj> lol
[16:09]  * frobware steps out of being bad to "kill" an instance... ???
[16:12] <mgz> frobware: you can now login to the webconsole via your canonical account and the details in cloud-city
[16:12] <frobware> mgz: thanks & trying now...
[16:14] <cherylj> frobware: would you be able to review https://github.com/juju/juju/pull/5790 ?
[16:14] <frobware> cherylj: we used to do this. then removed it - I mentioned this in the bug.
[16:16] <cherylj> frobware: ah, so the reasons need to be investigated ?
[16:16] <frobware> cherylj: the change is absolutely fine. it's the semantics that concern me a little.
[16:17] <frobware> cherylj: but... this could have been at a time when there were /other/ things that were broken.
[16:20] <frobware> cherylj: either way, I just commented in the PR
[16:20] <cherylj> thanks, frobware
[16:27] <frobware> dooferlad, voidspace, babbageclunk: PTAL @ http://reviews.vapour.ws/r/5234/
[16:27] <babbageclunk> frobware: looking
[16:35] <katco`> cherylj: wow, that got merged fast... is this the new branching structure in play? it doesn't look like any tests were run? http://juju-ci.vapour.ws:8080/job/github-merge-juju/8403/console
[16:39] <cherylj> umm.....
[16:39] <cherylj> balloons: can you look at http://juju-ci.vapour.ws:8080/job/github-merge-juju/8403/console ?
[16:39] <cherylj> oh, hmm
[16:39] <katco`> cherylj: i knew it was too good to be true =|
[16:39] <cherylj> maybe the output from the unit test isn't displayed anymore
[16:39] <cherylj> ?
[16:40] <cherylj> 2016-07-13 16:08:45 DEBUG Waiting for trusty to finish
[16:40] <cherylj> 2016-07-13 16:30:32 DEBUG trusty finished
[16:40] <katco`> ...
[16:40] <cherylj> 22 minutes seems reasonable
[16:40] <katco`> i'm not sure how i feel about that...
[16:40] <katco`> i guess if it succeeds you don't need the scrollback?
[16:40] <cherylj> "reasonable"
[16:40] <cherylj> yeah
[16:40] <cherylj> dunno
[16:40] <katco`> maybe we could at least put something there about "tests finished successfully"
[16:40] <natefinch> we used to print out the packages running tests... I don't think there's any reason not to do that
[16:40] <katco`> yeah
[16:41] <katco`> maybe if the io was causing slowdown, but i don't think that was the case?
[16:41] <cherylj> yeah, but if we're running multiple things in parallel, where would the output go?
[16:41] <katco`> oh it does say ALL passed
[16:42] <cherylj> I think we're just running trusty
[16:42] <cherylj> abentley: for the new parallel merge job, where is the output from the parallel jobs logged?
[16:42] <balloons> whart's our concern about the merge? The speed? The missing results in the console?
[16:42] <cherylj> balloons: the missing results made me think it hadn't run
[16:42] <abentley> cherylj: In the jenkins artifacts for the build.
[16:43] <balloons> http://juju-ci.vapour.ws:8080/job/github-merge-juju/lastSuccessfulBuild/artifact/artifacts/trusty-out.log/*view*/
[16:43] <katco`> balloons: i wasn't sure if the tests ran. i missed the "All passed, sending merge" which i assume is reerring to the tests?
[16:43] <balloons> well, I guess I should link to your specific build: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8403/artifact/artifacts/trusty-out.log/*view*/. But indeed they are there
[16:43] <natefinch> balloons: any reason not to just put that right in the jenkins console output?
[16:43] <cherylj> abentley: ah, got it
[16:44] <abentley> natefinch: The reason for not doing that is because we are running 3 sets of tests at once, and outputting the all at the same time would be confusing.
[16:44] <balloons> right. We could echo them to the console in order upon completion I suppose
[16:45] <abentley> balloons: I would like to do that for failing tests.  I'm not sure it's desirable for successes.
[16:45] <katco`> cherylj: did an email go out about this? looks like not everyone knew about the change?
[16:46] <balloons> well desire is a funny thing. Developers might rather have the giant log.
[16:46] <cherylj> katco: an email did go out
[16:46] <abentley> katco`: Yes, I sent it to juju-dev: "Windows and --race tests are now gating"
[16:46] <cherylj> katco: don't think it covered the change in the test output, maybe
[16:46] <abentley> cherylj: It did.
[16:46] <katco`> abentley: oh that one
[16:46]  * cherylj is corrected :)
[16:46] <katco`> abentley: must have missed that part
[16:46] <katco`> abentley: ty
[16:47] <cherylj> ha, we core devs are great about reading entire emails
[16:47] <balloons> anyways, I guess it's good that you are concerned about potential failures -- most would be happy it landed, but you care enough to know how it did so as well
[16:47] <balloons> kudos :-)
[16:47] <natefinch> abentley: could we at least write links to the console so we don't have to try to figure out how to get to the artifacts from that page?
[16:48] <katco`> cherylj: well i had thought i got the just of it: make sure your stuff works on windows :) i didn't expect additional information about log formatting in that chain
[16:48] <cherylj> lol
[16:48] <natefinch> katco`: ditto for me.  My bad for not reading the whole email.
[16:49] <katco`> balloons: goal is definitely a stable product, not jfdi ;)
[16:49] <abentley> natefinch: We could, but I would rather print out the logs for failures first, and then see if we still want it.
[16:50] <natefinch> abentley: I'd like the links printed out always, and then print out failures.  The test output has a lot of very useful information in it... like test times etc.
[16:50] <balloons> right, if you can adjust to the idea that no output is a "good thing", the output can become more usable and grokkable, as it will only ever have useful information of failures
[16:50] <natefinch> balloons: no output = good is very dangerous.  no output can also mean "nothing ran"
[16:51] <balloons> natefinch, well, you are getting a positive result back, so no output isn't literal
[16:52] <natefinch> balloons: ideally I'd like something like this for each test run - Windows: SUCCESS   output: http://juju-ci.vapour.ws:8080/job/github-merge-juju/lastSuccessfulBuild/artifact/artifacts/trusty-out.log/*view*/
[16:52] <natefinch> so, like, for example, it looks to me like the only thing we ran for this merge was trusty (so, no windows): http://juju-ci.vapour.ws:8080/job/github-merge-juju/8403/console
[16:52] <balloons> I've no desires either way, but I can definitely see both sides
[16:53] <balloons> the right amount of information at the right time should be the goal
[16:53] <abentley> balloons: That is the only thing we ran.  We are temporarily kneecapped.
[16:53] <abentley> natefinch: ^^
[16:54] <natefinch> abentley: understood
[16:54] <natefinch> abentley: for the record, I disagree with Ian.  The reason the tests on Windows don't pass is *because* we never make them gating.
[16:55] <katco`> natefinch: we have a spectrum of folks on the team: ||-(jfdi we're so busy)------(do it perfect or not at all)-||
[16:55] <abentley> natefinch: I'd say it's because CI failures don't block beta releases.
[16:55] <katco`> natefinch: as always, the middle-way is preferable
[16:57] <natefinch> abentley: I don't understand how we can ship anything, beta or not, if we know even one test is failing.  That means we *know* the product doesn't work.
[16:57] <natefinch> I mean, I do understand. We assume we know better than the test and that it's not *really* a bug.
[16:58] <natefinch> which is dangerous but also often true.
[16:58] <abentley> natefinch: The rationale with the betas is more like "It's a beta, it's allowed to have flaws".
[16:59] <katco`> abentley: natefinch: yes. and i think that direction comes from the top
[16:59] <katco`> natefinch: also, lots of products in beta (and even not) come out with a list of "known issues"
[17:01] <natefinch> I guess a bug with a failing test is better than a bug without one.... and we certainly have plenty of bugs without accompanying tests.
[17:27] <mup> Bug #1602780 opened: "cannot allocate memory" errors on 2.0beta11 controller <juju-core:New> <https://launchpad.net/bugs/1602780>
[17:32] <perrito666> bbl
[19:31] <mup> Bug #1556137 changed: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count> <oil> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1556137>
[19:31] <mup> Bug #1600300 changed: [2.0 RC1] can't install lxd  - E: The value 'trusty-backports' is invalid for APT - daily fix hasn't been promoted to release <oil> <oil-2.0> <cloud-images:Invalid> <juju-core:Invalid> <MAAS:Invalid> <maas-images:New> <https://launchpad.net/bugs/1600300>
[19:39] <bdx> hey whats up team? I've a few questions concerning network spaces on aws ...
[19:40] <bdx> 1. Is juju capable/aware of pre-existing subnets/networks associated with the aws account?
[19:41] <bdx> eeerrr ... * capable of using them, * aware that the networks exist
[19:43] <bdx> 1.a By what method can I instruct Juju to use the pre-existing subnets, if the functionality exists?
[19:43] <bdx> 2. Feature request if functionality doesn't exist?
[19:43] <bdx> 2.a Where can I find the docs on this functionality if it does exist?
[19:44] <bdx> can't seem to locate anything in juju's docs .. I know they are not complete ... guess I'm just hoping this is a thing ... anyone?
[19:45] <natefinch> bdx: most of the network gurus are on European time
[19:48] <natefinch> bdx: juju help add-subnet probably is what you want
[19:50] <niedbalski_> perrito666, natefinch quick question; I am facing https://bugs.launchpad.net/juju-core/+bug/1449633, there is any way to modify the db for flagging the stuck machines as non-voting? because right now, if i try to terminate (--force) those machine juju claims that 'machine xxx is required by the environment'.
[19:50] <mup> Bug #1449633: Cannot terminate/remove broken state server after ensure-availability <destroy-machine> <ensure-availability> <sts> <sts-needs-review> <juju-core:Triaged> <https://launchpad.net/bugs/1449633>
[19:51] <natefinch> niedbalski_: rerunning ensure-ha should mark them as non-voting and eventually remove them
[19:52] <mup> Bug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count> <oil> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1556137>
[19:52] <mup> Bug #1600300 opened: [2.0 RC1] can't install lxd  - E: The value 'trusty-backports' is invalid for APT - daily fix hasn't been promoted to release <oil> <oil-2.0> <cloud-images:Invalid> <juju-core:Invalid> <MAAS:Invalid> <maas-images:Confirmed> <https://launchpad.net/bugs/1600300>
[19:55] <mup> Bug # changed: 1556137, 1594958, 1595360, 1600300
[19:55] <natefinch> niedbalski_: it's possible this is an edge case that we can't recover from.  A replica never even being created due to lack of cloud availability is probably not something we have actively tested for.  I would hope that ensure-availability would do the right thing, but I can't be sure.
[19:55] <niedbalski_> natefinch, I don't see any evident effect, they remain in error state; and machine 0 keep screaming this: machine-0: 2016-07-13 19:54:39 ERROR juju.worker runner.go:223 exited "firewaller": machine 31 not provisioned
[19:56] <niedbalski_> natefinch, actually ha is working with another set of machines; but at the time we ran ensure-ha those machines failed to provision, now they are stuck in error state.
[19:56] <perrito666> niedbalski_: natefinch nuking the machines wont do the trick?
[19:58] <niedbalski_> perrito666, I would be more than happy to nuke them orelse flag them as non-voting and terminate those .. any trick?
[19:58] <natefinch> niedbalski_: have you tried the same thing in 1.25?  We did make some fixes at some point, though I don't know if any of them would have fixed this problem.
[19:58] <bdx> natefinch: oooh niceeee!  you da' man!
[19:58] <perrito666> natefinch: not sure I have enough authority in the subject to confidently say to nuke something
[19:59] <niedbalski_> natefinch, this is 1.25.5
[19:59] <natefinch> niedbalski_: oh, sorry, the bug mentioned 1.20.  Well, good, sorta
[20:00] <natefinch> niedbalski_: maybe try adding two new machines and doing ensure-availability --to x,y, where x and y are the new machines' numbers?
[20:01] <niedbalski_> natefinch, yep, that's the way we got ha working; now the issue is to get rid of the machines that remain in error state.
[20:01] <niedbalski_> 30         error                                    pending                                                        trusty
[20:01] <niedbalski_> 31         error                                    pending                                                        trusty
[20:04] <natefinch> niedbalski_: you might be stuck with them, unfortunately. It's probably worth a bug report to say that remove-machine --force should work if the server isn't even running yet (and/or is non-voting etc)
[20:05] <natefinch> niedbalski_: you could, in theory, go hack the database, but it's not something I'd feel super comfortable about.
[20:07] <niedbalski_> natefinch, understood, I'll fill an extra bug; I don't feel comfortable with hacking the database, but those stuck errored machines are driving me somehow crazy.
[20:08] <natefinch> niedbalski_: make an alias for juju status that strips them out ;)
[20:10] <niedbalski_> natefinch, lol .. yeah, probably I can mock the status output too.
[20:58] <mup> Bug #1602838 opened: Charm upgrade should use bulk calls for whole model, not one per charm <juju-core:New> <https://launchpad.net/bugs/1602838>
[20:58] <mup> Bug #1602840 opened: juju status (or equivalent) should show all addresses a machine has <network> <status> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1602840>
[21:24] <frobware> anybody succesfully deploying LXD containers today? I ask because the download seems to stop at about 30% for me then nothing more.
[21:26] <frobware> well, well... it may be something at my end as downloading latest from kernel.org also hangs at ~40%
[21:27]  * frobware goes to bed and hopes the internet fairies sprinkle unicorns over his internet connection....
[21:28] <mup> Bug #1598708 changed: juju use many DEPRECATED apis ,is there new juju version using the latest api? <juju-core:New> <https://launchpad.net/bugs/1598708>
[22:38] <wallyworld> veebers: the latest log forward stuff has just landed, cpu issue hopefully fixed
[22:39] <veebers> wallyworld: awesome, I'll give it a spin shortly
[22:39] <wallyworld> hope it works :-)
[22:40] <veebers> heh I'll let you know either way :-)
[22:57] <arosales> hello juju-core devs :-)
[22:57] <arosales> I am hitting a lxd perms issue
[22:57] <arosales> http://paste.ubuntu.com/19316751/
[22:58] <arosales> is there a work around for this?
[22:58] <veebers> wallyworld: quick Q: what's the best way to get a models (i.e. the controller) uuid? I'll be using it to confirm the right log message appears in the rsyslog sink
[22:58]  * arosales tried to reconfigure the network per https://jujucharms.com/docs/devel/getting-started but no luck
[22:58] <arosales> hit this on beta7, beta10, and beta 11
[22:59] <wallyworld> veebers: juju show-controller --format yaml should print the controller uuid i think
[23:00] <veebers> wallyworld: cheers
[23:00] <wallyworld> arosales: i've not seen that particular issue. thumper? ^^^^
[23:01]  * thumper looks
[23:01]  * arosales trying to clean up other containers to see if thats the issue
[23:01] <thumper> ah... nope
[23:04] <veebers> wallyworld: fyi that works, thanks
[23:04] <wallyworld> veebers: awesome, thanks for testing
[23:05] <veebers> wallyworld: oh sorry to mislead , that was re: show-controller. I'll have tested the cpu stuff soon :-P
[23:05] <alexisb_> arosales, I have bootstraped several times on lxd in the last week (both from devel, beta7 and master) and not seen that issue
[23:05] <arosales> alexisb_: on Z :-)
[23:05] <alexisb_> ah ok
[23:05] <arosales> ?
[23:05] <alexisb_> that I have not done
[23:06] <arosales> :-(
[23:06] <alexisb_> :)
[23:07] <alexisb_> arosales, someone on the QA team can provide details on system z tests in CI, maybe balloons
[23:07] <alexisb_> if he is still around
[23:07] <arosales> alexisb_: ok I see if any qa folks respond
[23:08] <arosales> alexisb_: thanks
[23:08] <arosales> got some z folks interested in a juju demo tomorrow and would like to show 20
[23:08] <arosales> 2.0
[23:08] <arosales> but . . . .the above error is a little bit of an issue
[23:08] <arosales> luckily 1.25 is working
[23:11] <alexisb_> arosales, looking at this we have many working lxd deploys on s390x: http://reports.vapour.ws/releases/4135/job/lxd-deploy-xenial-s390x/attempt/217
[23:13] <alexisb_> arosales, not that that really helps for your specific issue
[23:13] <arosales> alexisb_: well good to know that is has been working
[23:13] <arosales> alexisb_: thanks for the information
[23:37] <mup> Bug #1602885 opened: machine allocation failed due to maas error, but machines stay in pending state forever <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1602885>
[23:43] <axw> wallyworld: it was a combination of my code and your code that caused the problem, so I eat my words
[23:43] <wallyworld> we both suck :-)
[23:43] <axw> wallyworld: the provider is using StateServingInfo, should be using ControllerConfig
[23:44] <wallyworld> hmm, i thought it was using controller config, oh well
[23:44] <axw> wallyworld: my change made it so that StateServingInfo is no longer populated when the Environ.Bootstrap call is made
[23:44] <axw> wallyworld: I'm planning to make InstanceConfig write-only when I get some time, any input should be in StartInstanceParams
[23:45] <wallyworld> ok
[23:50] <thumper> menn0: http://reviews.vapour.ws/r/5167/diff/# updated
[23:53]  * perrito666 is back