=== rodlogic is now known as Guest90697 === rodlogic is now known as Guest28228 [01:01] evening [01:04] rick_h_: morning \o/ [01:05] how goes anastasiamac? [01:05] rick_h_: foggy :D [01:05] anastasiamac: :) [01:05] anastasiamac: well sun just went down here so hope it heads your way to burn that away [01:05] rick_h_: couldn't see anything out of windscreen when taking kids to school... everyone is crawling :D sun would b nice \o/ [01:06] rick_h_: how r u? how was pacific island? [01:07] anastasiamac: good, catching up this weekend. hawaii was good stuff [01:07] lots of time on boats and looking at fishies :) [01:07] rick_h_: wow! this is how I feel about bugs :D [01:07] lol [01:07] rick_h_: great to hear u r rested :) [01:08] anastasiamac: <3 [01:08] anyone about? I'm having a really weird issue with a multi phase juju-deployer deployment - the first few stages work fine, but the final one took 40 hours over the weekend to progress from "deployer.cli: Using runtime GoEnvironment on maas" to "Starting deployment of..". The machine-0 state server is all kinds of screwed up too, its erroring with TLS handshake errors, and various other broken pipe errors [01:11] bradm: not sure, what version of deployer and juju? [01:12] rick_h_: juju-deployer 0.6.1-1~ubuntu14.04.1~ppa1 and juju-core 1.25.5-0ubuntu1~14.04.2~juju1 [01:13] rick_h_: I'm wondering if its somehow related to LP#1575448, since its the state server thats throwing all these errors [01:14] all the other machine units are shutting down since they can't talk to juju state server [01:14] anastasiamac: have you peeked at ^ any more? [01:14] Bug #1579592 opened: SSH commands don't verify proxy host

[01:15] bradm: :/ sorry not sure. [01:15] rick_h_: it was my focus for today :D [01:15] anastasiamac: ok, can you keep bradm in touch if you find anything to try please? [01:15] rick_h_: sure [01:16] I can focus on something else for a while, need to look at getting the charms to understand systemd in the checks, and wait to see if anything happens with the other bug. [01:16] bradm: k, ty for letting anastasiamac investigate [01:18] it doesn't seem like a stretch that if the HA version of the state server is having issues that the non-HA version would too [01:18] although why others aren't seeing it, I don't know. [01:45] Bug #1579593 opened: SSH host keys for bootstrap aren't checked

[01:54] is it still applicable with mongo3? https://bugs.launchpad.net/juju-core/+bug/1447390 [01:54] Bug #1447390: mongo tools missing on centos

[02:21] wallyworld: perrito666: with fixes to backup and restore that u r focusing on, has there been any movements in the related bugs? [02:21] for e.g.: https://bugs.launchpad.net/juju-core/+bug/1493458 [02:21] Bug #1493458: backups restore: fails when machine number differs

[02:22] and surely this is improving :D https://bugs.launchpad.net/juju-core/+bug/1545568 [02:22] Bug #1545568: api/backups/restore.go has no unit tests

[02:22] and this https://bugs.launchpad.net/juju-core/+bug/1545562 [02:22] Bug #1545562: Restore assumes systemd present on machines

[02:22] the systemd one might be fixed [02:23] the machine number one is an old bug - may have been fixed incidentally [02:23] we'd really need to audit what's there once the current mongo 3.2 compatibility issues have been solved [02:23] update in the bugs would b amazing, even if it's just a progress update [02:23] no one is actively working those bugs [02:23] i didn't even know they existed [02:24] u do now \o/ [02:24] we'll need to fix the current mongo 3.2 issues first [02:25] wallyworld: m not syaing "these need to addressed now", m saying that "we have these and they are in the area where there is current movement... r they still applicable or r they addressed as part of something else?" [02:26] like surely we are putting *some* api tests in the area?.. [02:26] no, because the api is not changing [02:26] we are fixing the backend implrementation [02:27] the scope of the current work is constrained to mongo 3.2 compatibility [02:27] those other bugs may or may not be still current - but any investigation will need to come as a separate piece of work [02:28] it is hard enough to fix the mongo 3.2 issues without scope creep for addtional, unrelated bugs [02:29] we can add those to the bug board [02:29] they can be investigated in parallel with the current work, as they are not related [02:29] m not saying "fix"... \o/ [02:30] m saying " u r in the area, have u encountered these?" so that we can determine if they r still current :D [02:36] haven't encountered those, but we have not even been looking out for them. the testing done has been very tightly constrained to a simple restore scenario based on mongo 3.2 [02:37] ie we would not have a scenario where the machine nuimber differs, as we are restoring with the -b option [02:37] and testing todate has been on xenial (mongo 3.2), so systemd is always there [02:39] thank you for update and clarification [02:41] sorry that there' been no activity in those other areas [02:41] yes :D very disappointing :-P [03:27] wallyworld: axw: i seem to recal that this has been addressed, non? https://bugs.launchpad.net/juju-core/+bug/1316874 [03:27] Bug #1316874: How to specify an environment to be specific series

[03:27] Bug #1494787 changed: bootstrap cannot be interrupted if machine agent fails to start [03:27] Bug #1510875 changed: unable to interrupt 'juju boostrap' on MAAS before the node is running

[03:27] anastasiamac: set-model-config default-series=... [03:27] and bootstrap-series arg for the controller [03:28] axw: this is about "juju bootstrap --series=" [03:28] hmm i guess bootstrap-series even [03:28] the first bug above talks about environment (model) [03:28] anastasiamac: it's not? the issue is about the model series [03:28] and that's what "default-series" is [03:28] yep [03:29] there's 2 series here - the model series and the controller series [03:29] k.. axw: so old bug pre model/controller distinction :D [03:30] both talk about "bootstrap" so probably intended artifacts are controllers [03:30] to get a controller of particular series we use "juju bootstrap -bootstrap-series"? [03:30] anastasiamac: yeah, at the time the bug was filed, there was no multi-model [03:31] to get a model of particular series..? [03:31] anastasiamac: correct [03:31] anastasiamac: a model doesn't really ahve a series, but setting default-series means all machines will take that series unless otherwise specified [03:32] axw: so is there any means of overwritting default-series? what do u mean by "otherwise" specified? [03:32] anastasiamac: "juju add-machine --series=..." [03:35] axw: it's for machines... so nothing specific for models, right? just default-series (if u want to overwrite what's against controller) [03:36] anastasiamac: I don't understand. defualt-series is model config. it controls what series a machine is assigned unless something else specifies a series [03:36] Bug #1494787 opened: bootstrap cannot be interrupted if machine agent fails to start [03:36] anastasiamac: you can use the usual commands to get/set default-series in model config. [03:36] Bug #1510875 opened: unable to interrupt 'juju boostrap' on MAAS before the node is running

[03:39] Bug #1494787 changed: bootstrap cannot be interrupted if machine agent fails to start [03:39] Bug #1510875 changed: unable to interrupt 'juju boostrap' on MAAS before the node is running

[03:39] axw: k - thnx \o/ . so to create a model in particular series "juju add-model --config default-series=..." [03:39] yep [03:48] axw: since u have mentioned "add-machine --series=..." any idea if this is fixed? https://bugs.launchpad.net/juju-core/+bug/1273216 [03:48] Bug #1273216: unknown --series to add-machine breaks provisioner

[03:48] anastasiamac: no idea [03:49] axw: k [03:51] Bug #1316874 changed: How to specify an environment to be specific series

[03:51] Bug #1317666 changed: bootstrap CLI should have an option to specify target series (phase 2)

[04:38] i think this is fixed https://bugs.launchpad.net/juju-core/+bug/1254402... anyone know any different? [04:38] Bug #1254402: error bootstrapping on ec2 duplicate security group

[04:42] Bug #1305279 changed: default-series is the only way to set the series of the state-server

=== Garyx_ is now known as Garyx [07:10] Bug #1579633 opened: state.leadershipClient used unsafely

=== frankban|afk is now known as frankban [08:22] Bug #1537740 changed: sudo error on bootstrap and working on units

[08:31] Bug #1537740 opened: sudo error on bootstrap and working on units

[08:40] Bug #1537740 changed: sudo error on bootstrap and working on units

[09:01] dimitern: frobware: be right there for standup - grabbing coffee! [09:05] dimitern: hmmm, actually - frobware is away [09:14] fwereade: dimitern: dooferlad: firefox crash! [09:14] brb === Garyx_ is now known as Garyx [09:39] mgz: ping [10:47] fwereade: ping [10:48] fwereade: so the reason the MAAS 2 bundle deploy test fails (as far as we can tell) is that it bootstraps with a custom streams url for the tools - which works fine but isn't propagated to the model that deploys the bundle. The bundle deploy then fails because it attempts to use the standard tools url. [10:49] fwereade: is this expected behaviour - that if you use custom settings like this you need to "manually propagate" them to models [10:51] voidspace, not that I am aware of... anastasiamac, wallyworld, thoughts on the above? [10:52] fwereade: still need to confirm that's *really* the problem, but it seems to be what the logs are showing [10:52] voidspace: fwereade: correct, hosted models ony inherit a subset of properties from their controller admin model [10:52] this was from tim's original design [10:52] wallyworld: including the default model immediately after bootstrap [10:53] yes [10:53] hosted models are their own thing [10:53] with their own attributes [10:53] so you bootstrap with settings and immediately have to reapply those settings [10:53] and DRY be damned :-) [10:53] depends on what your needs are [10:53] why should a hosted model be forced to get it's tools from the same place as the admin model [10:54] sure, it's a nice design principle to make simple cases simple [10:54] anyways, that was the design (not mine) [10:54] wallyworld: thanks for confirming [10:54] that's from memory - i'd have to double check to see [10:54] let me do that in case my memory is flawed [10:55] it very much seems so from the logs we're seeing [10:55] it's easy enough to work around now we know [10:56] wallyworld, voidspace: I thought tools streams were meant to be per-controller though [10:56] voidspace: so there's a method on Environ called RestrictedConfigAttributes() [10:56] that defines attributes that need to be the same between models withon a controller [10:56] wallyworld, voidspace: if I'm running a controller I don't want you guys to run heaven-knows-what agent code in your environment [10:57] fwereade: i don't know to be honest, what the original design constraints were [10:58] voidspace: fwereade: as implemented, these are shared [10:58] "type", [10:58] config.CACertKey, [10:58] "state-port", [10:58] "api-port", [10:58] config.ControllerUUIDKey, [10:58] plus provider specific restricted attributes [10:59] as far as i can tell from the code, the model uses its own valeus for everythign else [10:59] wallyworld: thanks [10:59] but i'll dig a bit deeper [10:59] the above just restricts what can't be overridden [11:03] voidspace: fwereade: yeah, so digging a bit more, it does seem that the model needs to supply its own values. the exceptions are 1. creds are inherited if you are the controller admin, 2. restricted values may be specified in the model config but must match whatever the controller has, or else that's an error [11:04] so agent stream or agent url is not inherited from what i can see [11:04] if that original design from way back when is wrong, then we can fix [11:06] probably worth a discussion on juju-core, or an executive decision [11:07] http://paste.ubuntu.com/16316990/ === Garyx_ is now known as Garyx [11:56] dimitern: a bunch of tests for AllocateContainerAddresses http://reviews.vapour.ws/r/4790/ [11:56] voidspace: looking [11:56] dimitern: I still want to write tests for deviceInterfaceInfo2 as well [12:02] voidspace: in cases where you have a bunch of fake types embedding a *testing.Stub I found it quite useful to share a single stub across multiple types, so the CheckCalls can be done on the same shared stub [12:05] voidspace: but ofc ymmv [12:05] dimitern: I'm only ever checking one stub at a time, and sharing would actually mean an extra line of code [12:05] :-) [12:05] arguably cleaner but arguably not [12:05] dimitern: useful if I do need to do multiple checks - thanks [12:05] voidspace: I can show you not very good examples of too much sharing done :) [12:05] hehe [12:06] I've tried to scope the tests to a single point [12:06] so one interesting stub per test falls out of that [12:06] although each test still needs all the setup for the previous test :-/ [12:07] and sharing the stubs would be a nuisance for the SetErrors call [12:07] voidspace: how about splitting the setup steps in mini helpers, easy to compose [12:07] dimitern: I thought about it - I could avoid *some* duplication [12:08] however later tests modify the earlier setup stages too [12:08] (more machines, more subnets, more interfaces etc) [12:08] so wouldn't help as much as you'd hope [12:09] dimitern: I have some more tests to write - and in the PR for that I can look at consolidation, ok? [12:09] voidspace: well, you could have a subnet := makeFakeSubnet(3)... [12:10] true enough [12:10] voidspace: sounds good, I'll add some suggestions [12:10] dimitern: thanks [12:16] voidspace: reviewed [12:21] dimitern: thanks [12:42] does anyone know if anyone's tried adding http/2 support into the apache2 charm? [12:43] voidspace: pretty sure the only reason the bundle deploy test fails on maas 2.0 is bug 1568895 [12:43] Bug #1568895: Cannot add MAAS-based LXD containers in 2.0beta4 on trusty

[12:44] at least that was the case start of last week, now it seems somewhat unhappy even with lxc containers [12:44] nottrobin: you're probably better off asking in #juju - but you can also see the various branches on launchpad [12:47] hey guys, trying to run juju from source after a while of not doing so. i get a bunch of scary output from `go get`, am i missing something? http://pastebin.ubuntu.com/16317624/ [12:49] mgz: okay I'll go ask in #juju. But do you know how I can see a list of just charms/apache2 branches in launchpad? [12:50] tvansteenburgh: use godeps? [12:51] nottrobin: seems to be https://code.launchpad.net/charms/+source/apache2 [12:52] mgz: thanks [12:53] nottrobin: there's also a trusty series link at the bottom with more [12:53] yeah I found that. thanks [12:59] mgz thanks === rodlogic is now known as Guest30270 [13:08] Bug #1579750 opened: Wrong hostname added to dnsmasq using LXD [13:14] mgz: the error it fails with is "no matching tools" for machine 0 [13:15] mgz: which doesn't seem like a lxd container issue [13:20] voidspace: I don't see that, looking at maas-2.0-bundle-deploy [13:25] mgz: http://reports.vapour.ws/releases/3955/job/maas-2_0-bundle-deploy/attempt/12 [13:25] mgz: machine "0", "no tools available" [13:26] mgz: and the failure reason, "ErroredUnit: 0 is in state error" [13:26] mgz: that's the latest run on master [13:27] mgz: the other deploy-bundle tests succeeded [13:29] voidspace: hm, on that revision only. also, compare http://juju-ci.vapour.ws/job/maas-2_0-bundle-deploy/14/ [13:29] same rev, only change, bundle with lxc containers not lxd [13:30] mgz: 404 [13:31] voidspace: login. [13:31] mgz: I am logged in [13:31] ah, not to that service maybe [13:31] voidspace: navigate to the job if I tyoped it. but you want the developer creds from cloud-city consoles.txt [13:32] Bug #1579057 changed: Race in github.com/juju/juju/worker/catacomb/catacomb

[13:32] it looks to me like 12 failed because the machines didn't come up cleanly [13:32] we don't have addresses for 0 or 1 in the non-admin model [13:32] so, the tools thing looks like a red herring [13:32] mgz: what credentials do I use for juju-ci.vapour - it's not using SSO as far as I can see [13:33] mgz: ah, thanks [13:33] mgz: not sure if you tyoped it or not... === rodlogic is now known as Guest93463 [13:42] mgz: if you look in logsink for 12 you do see it trying the "wrong address" for the tools for machine 0 [13:42] mgz: so I'm not convinced yet :-) [13:42] mgz: you're likely to be right, I'm just not convinced yet... [13:50] voidspace: what went wrong on that job is an interesting question, but it's not been the main cause of failure [14:02] Bug #1578286 changed: Juju2 cannot deploy windows workloads on maas 1.9

[14:02] Bug #1579062 changed: localHTTPSServerSuite no trusty arm64/ppc64el images

=== rodlogic is now known as Guest80695 [15:01] natefinch: standup time === rodlogic is now known as Guest20915 [15:13] evilnick: is `juju help glossary` on your list of things to fix already? or should I file a bug? [15:13] oh, someone killed it already [15:14] yes, it was me [15:14] evilnick: good job, it was terrible. [15:14] mgz there is a 'concepts page' now [15:14] it still nees work [15:15] evilnick: I have one other thing, our rackspace help currently references a temp bucket CI uses, which got nuked and recreated [15:15] I'd prefer not to give our config at all (and there's hope we'll have proper support in the near future anyway) [15:16] but I could link my script/instructions for creating the image streams yourself instead [15:16] which is basically lp:juju-ci-tools rackspace-generate-image-streams.bash [15:16] or we could update to the new temp streams and hope it can just go away soon [15:32] mgz, yes, I'm aware. I got bored of people complaining they couldn't use it after it appeared in the beta release notes [15:33] evilnick: that's fair enough [15:33] evilnick: I'm happy to put up a proposal with the new magic url for now [15:33] mgz, I hope it will solve itself, but yes, any nonsense you want to add/subtract gratefully received [15:59] Bug #1210593 changed: Show the user all current running environments

[15:59] Bug #1240431 changed: Allow constraints to be set for only the bootstrap node [16:02] trivial deps review anyone? perrito666, katco, ericsnow: http://reviews.vapour.ws/r/4791/ [16:02] Bug #1210593 opened: Show the user all current running environments

[16:02] Bug #1240431 opened: Allow constraints to be set for only the bootstrap node [16:03] natefinch: looking [16:03] natefinch: do you know what the systemd update enails? [16:03] entails* [16:05] perrito666: no.. honestly, I don't know what the godbus changes entail, other than my fix. I suppose I should look at that on both repos. [16:05] perrito666: both repos were over a year out of date [16:06] natefinch: ship it [16:06] perrito666: CI will catch breakages, right? :) [16:06] * perrito666 slaps natefinch in the back of the head [16:06] perrito666: why even have CI if you can just throw things over the wall [16:06] s/can/can't [16:06] * natefinch is sure it'll be fine. === ejat is now known as fenris- === fenris- is now known as ejat === ejat is now known as fenris- === fenris- is now known as ejat === rodlogic is now known as Guest12850 [16:17] Bug #1210593 changed: Show the user all current running environments

[16:17] Bug #1240431 changed: Allow constraints to be set for only the bootstrap node [16:56] katco, ping [17:00] Bug #1579833 opened: Initial admin cannot log out

[17:00] Bug #1579836 opened: repeated login attempt to websockets api results in confusing error message

[17:06] Bug #1579833 changed: Initial admin cannot log out

[17:06]