| 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:07 |
| redir | tanzanite? | 00:08 |
| wallyworld | ok | 00:08 |
| 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 | 00:29 |
| thumper | menn0: http://reviews.vapour.ws/r/5230/ | 01:01 |
| menn0 | thumper: will take a look in a sec | 01:05 |
| 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:06 |
| 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:32 |
| 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:33 |
| mup | Bug #1602010 changed: juju status doens't display proper error when machine fails <juju-core:New> <https://launchpad.net/bugs/1602010> | 01:58 |
| 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 | 01:59 |
| 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:00 |
| 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:02 |
| 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:35 |
| wallyworld | ok | 02:36 |
| 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:51 |
| 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:52 |
| 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> | 02:58 |
| 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:01 |
| 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:07 |
| menn0 | thumper: ship it for 5230 | 03:08 |
| menn0 | wallyworld: chat? | 03:08 |
| thumper | menn0: cheers | 03:08 |
| 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:09 |
| 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:47 |
| wallyworld | axw: minor typo. so the private key should just go to state serving info (from memory) and nowhere else | 03:53 |
| wallyworld | it is used by the cert update worker | 03:54 |
| axw | wallyworld: thanks. yes, that is correct | 03:54 |
| wallyworld | so godd that it is also removed from controller config as nothing else needs to see it | 03:55 |
| wallyworld | good | 03:55 |
| mup | Bug #1602508 opened: LastLogTracker accesses mongo collections directly <2.0> <juju-core:Triaged> <https://launchpad.net/bugs/1602508> | 05:02 |
| wallyworld | axw: when you have time, here's that log forward fix http://reviews.vapour.ws/r/5231/ | 05:29 |
| axw | wallyworld: reviewed | 05:41 |
| wallyworld | ta | 05:41 |
| axw | argh, juju-ci is Service Unavailable | 05:43 |
| 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:44 |
| wallyworld | fair enough, i was being overly cautious i guess | 05:45 |
| wallyworld | axw: fixed | 05:52 |
| 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:54 |
| axw | interesting | 05:55 |
| axw | jam: it was changed from SetList to SetLastSent | 05:58 |
| jam | axw: ah, just read it backwards then. | 06:11 |
| jam | thanks | 06:11 |
| wallyworld | axw: the juju login command - where does that write to the db? ie the macaroon and record of login | 06:47 |
| 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:54 |
| wallyworld | axw: np, thanks. i'm commenting on https://docs.google.com/document/d/1xRO2tbeC-Dg5JdSV-wMYIZQel11EfWqPk8LU-0XdH8Y | 06:55 |
| 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:57 |
| axw | wallyworld: do you recall why you made this change? https://github.com/juju/juju/commit/f751ea7b54876a5a38dbef6dfc90e1d56b1531d5 | 06:58 |
| axw | wallyworld: I'm trying to weed out unnecessary environs.Environ constructions, this code stuck out as a bit odd | 06:59 |
| 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:00 |
| 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:02 |
| wallyworld | axw: can you join us? https://hangouts.google.com/hangouts/_/canonical.com/regular-catchup | 07:19 |
| axw | wallyworld: be there in a moment | 07:20 |
| jam | frobware: ping | 07:34 |
| rogpeppe2 | axw: hiya | 07:55 |
| axw | rogpeppe2: hey | 07:55 |
| === rogpeppe2 is now known as rogpeppe | ||
| 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:56 |
| 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:57 |
| axw | so models.yaml shouldn't need the account qualifier. they would implicitly be relative to the logged-in user | 07:58 |
| 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 | 07:59 |
| rogpeppe | axw: wouldn't you still need accounts.yaml 'cos you can still have a different user for each controller? | 08:00 |
| 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:01 |
| 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:30 |
| 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> | 08:38 |
| === admcleod_ is now known as admcleod | ||
| thumper | night all | 09:02 |
| axw | rogpeppe: back. looking... | 09:03 |
| axw | rogpeppe: suggested approach of changes to accounts.yaml? | 09:05 |
| rogpeppe | axw: well, of changes to models.yaml really | 09:05 |
| 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:06 |
| 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:07 |
| 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:10 |
| mup | Bug #1602591 opened: Juju 2.0 Resources: Issue while fetching empty resources from charm store <juju-core:New> <https://launchpad.net/bugs/1602591> | 09:14 |
| 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:20 |
| axw | mgz: are you around? do you know juju-ci is busted? | 10:21 |
| frobware | dooferlad: ping - do you some time to look over my sholder at some networky things.... | 10:47 |
| dooferlad | frobware: sure | 10:47 |
| frobware | dooferlad: 1:1 HO | 10:48 |
| axw | rogpeppe: https://github.com/juju/juju/pull/5788 | 11:09 |
| perrito666 | morning all | 11:39 |
| axw | rogpeppe: back for 10 mins or so - how's it going? | 12:14 |
| mgz | axw: yeah, it's I think just the proxy server, master seems to be up and doing things | 12:18 |
| axw | mgz: when I ssh'd to the machine, the jenkins job log said the agent had terminated or something like that | 12:19 |
| mgz | have restarted jenkins to see if it get stuck in the same loop | 12:23 |
| 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 | 12:25 |
| rogpeppe | axw: sorry, was on lunch | 13:26 |
| cherylj | mgz: got a few to help me look at the 1.25 CI failures? | 14:03 |
| babbageclunk | Help - does anyone know about how cloud-init works? | 14:04 |
| mgz | cherylj: sure, daily hangout? | 14:04 |
| cherylj | mgz: yeah, omw | 14:05 |
| cherylj | babbageclunk: you may have some luck asking in #cloudware on the canonical IRC | 14:05 |
| babbageclunk | Ok, thanks - I pinged smoser but caught him on the way out. | 14:06 |
| frobware | anybody see this "bad ports from GCE: invalid port range 0-0/tcp" from GCE recently? | 14:22 |
| 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:45 |
| 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 | 14:59 |
| perrito666 | controlleruuid and controllermodeluuid are the same always? and if so, is that by design? | 15:06 |
| alexisb_ | frobware, looks like a bug just got opened | 15:09 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| lazyPower | that makes sense why i haven't seen it if its only affecting master | 15:22 |
| cherylj | lazyPower: yeah, just injected yesterday | 15:23 |
| natefinch | gah, who decided that github.com/juju/juju/cloud.Cloud shouldn't have a Name field :/ | 15:36 |
| natefinch | one might assume the name of a cloud might be important info :/ | 15:38 |
| perrito666 | oh, great, another breaking change, people is going ot hate me | 15:43 |
| alexisb_ | perrito666, what change? | 15:44 |
| perrito666 | alexisb_: oh, not that breaking | 15:44 |
| frobware | mgz: thanks for raising the bug | 15:44 |
| 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:45 |
| 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:51 |
| 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:52 |
| 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:54 |
| cherylj | you'll need to add the blocker tag too to use the $$fixes-####$$ notation | 15:55 |
| katco` | cherylj: ah ok | 15:55 |
| frobware | dooferlad: thanks for the link to the alias bug | 15:57 |
| dooferlad | frobware: I assume that is sarcasm... | 15:59 |
| frobware | dooferlad: check! | 15:59 |
| frobware | sigh | 15:59 |
| frobware | dooferlad: we used to bridge aliases but removed it. I cannot immediately recally why we removed bridges for aliases... | 16:00 |
| natefinch | oh man, we love spooky action at a distance in this codebase | 16:03 |
| 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:04 |
| 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:05 |
| * 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:06 |
| 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:07 |
| mgz | frobware: I can add you if you promise to be good | 16:08 |
| 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:09 | |
| 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:12 |
| 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:14 |
| 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:16 |
| frobware | cherylj: but... this could have been at a time when there were /other/ things that were broken. | 16:17 |
| frobware | cherylj: either way, I just commented in the PR | 16:20 |
| cherylj | thanks, frobware | 16:20 |
| === akhavr1 is now known as akhavr | ||
| frobware | dooferlad, voidspace, babbageclunk: PTAL @ http://reviews.vapour.ws/r/5234/ | 16:27 |
| babbageclunk | frobware: looking | 16:27 |
| 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:35 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| balloons | natefinch, well, you are getting a positive result back, so no output isn't literal | 16:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:57 |
| 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:58 |
| 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" | 16:59 |
| 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:01 |
| mup | Bug #1602780 opened: "cannot allocate memory" errors on 2.0beta11 controller <juju-core:New> <https://launchpad.net/bugs/1602780> | 17:27 |
| === mup_ is now known as mup | ||
| perrito666 | bbl | 17:32 |
| 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:31 |
| bdx | hey whats up team? I've a few questions concerning network spaces on aws ... | 19:39 |
| bdx | 1. Is juju capable/aware of pre-existing subnets/networks associated with the aws account? | 19:40 |
| bdx | eeerrr ... * capable of using them, * aware that the networks exist | 19:41 |
| 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:43 |
| 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:44 |
| natefinch | bdx: most of the network gurus are on European time | 19:45 |
| natefinch | bdx: juju help add-subnet probably is what you want | 19:48 |
| 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:50 |
| natefinch | niedbalski_: rerunning ensure-ha should mark them as non-voting and eventually remove them | 19:51 |
| 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:52 |
| 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:55 |
| 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:56 |
| 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:58 |
| niedbalski_ | natefinch, this is 1.25.5 | 19:59 |
| natefinch | niedbalski_: oh, sorry, the bug mentioned 1.20. Well, good, sorta | 19:59 |
| 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:00 |
| 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:01 |
| 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:04 |
| natefinch | niedbalski_: you could, in theory, go hack the database, but it's not something I'd feel super comfortable about. | 20:05 |
| 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:07 |
| natefinch | niedbalski_: make an alias for juju status that strips them out ;) | 20:08 |
| niedbalski_ | natefinch, lol .. yeah, probably I can mock the status output too. | 20:10 |
| 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> | 20:58 |
| === natefinch is now known as natefinch-afk | ||
| frobware | anybody succesfully deploying LXD containers today? I ask because the download seems to stop at about 30% for me then nothing more. | 21:24 |
| frobware | well, well... it may be something at my end as downloading latest from kernel.org also hangs at ~40% | 21:26 |
| * frobware goes to bed and hopes the internet fairies sprinkle unicorns over his internet connection.... | 21:27 | |
| 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> | 21:28 |
| wallyworld | veebers: the latest log forward stuff has just landed, cpu issue hopefully fixed | 22:38 |
| veebers | wallyworld: awesome, I'll give it a spin shortly | 22:39 |
| wallyworld | hope it works :-) | 22:39 |
| veebers | heh I'll let you know either way :-) | 22:40 |
| arosales | hello juju-core devs :-) | 22:57 |
| arosales | I am hitting a lxd perms issue | 22:57 |
| arosales | http://paste.ubuntu.com/19316751/ | 22:57 |
| 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:58 |
| wallyworld | veebers: juju show-controller --format yaml should print the controller uuid i think | 22:59 |
| veebers | wallyworld: cheers | 23:00 |
| wallyworld | arosales: i've not seen that particular issue. thumper? ^^^^ | 23:00 |
| * thumper looks | 23:01 | |
| * arosales trying to clean up other containers to see if thats the issue | 23:01 | |
| thumper | ah... nope | 23:01 |
| veebers | wallyworld: fyi that works, thanks | 23:04 |
| wallyworld | veebers: awesome, thanks for testing | 23:04 |
| 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:05 |
| arosales | :-( | 23:06 |
| alexisb_ | :) | 23:06 |
| 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:07 |
| 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:08 |
| 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:11 |
| 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:13 |
| 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:37 |
| 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:43 |
| 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:44 |
| wallyworld | ok | 23:45 |
| thumper | menn0: http://reviews.vapour.ws/r/5167/diff/# updated | 23:50 |
| * perrito666 is back | 23:53 | |
| === urulama is now known as urulama|___ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!