[01:01] <rick_h_> evening
[01:04] <anastasiamac> rick_h_: morning \o/
[01:05] <rick_h_> how goes anastasiamac?
[01:05] <anastasiamac> rick_h_: foggy :D
[01:05] <rick_h_> anastasiamac: :)
[01:05] <rick_h_> anastasiamac: well sun just went down here so hope it heads your way to burn that away
[01:05] <anastasiamac> 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] <anastasiamac> rick_h_: how r u? how was pacific island?
[01:07] <rick_h_> anastasiamac: good, catching up this weekend. hawaii was good stuff
[01:07] <rick_h_> lots of time on boats and looking at fishies :)
[01:07] <anastasiamac> rick_h_: wow! this is how I feel about bugs :D
[01:07] <rick_h_> lol
[01:07] <anastasiamac> rick_h_: great to hear u r rested :)
[01:08] <rick_h_> anastasiamac: <3
[01:08] <bradm> 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] <rick_h_> bradm: not sure, what version of deployer and juju?
[01:12] <bradm> 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] <bradm> rick_h_: I'm wondering if its somehow related to LP#1575448, since its the state server thats throwing all these errors
[01:14] <bradm> all the other machine units are shutting down since they can't talk to juju state server
[01:14] <rick_h_> anastasiamac: have you peeked at ^ any more?
[01:14] <mup> Bug #1579592 opened: SSH commands don't verify proxy host <security> <juju-core:New> <https://launchpad.net/bugs/1579592>
[01:15] <rick_h_> bradm: :/ sorry not sure.
[01:15] <anastasiamac> rick_h_: it was my focus for today :D
[01:15] <rick_h_> anastasiamac: ok, can you keep bradm in touch if you find anything to try please?
[01:15] <anastasiamac> rick_h_: sure
[01:16] <bradm> 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] <rick_h_> bradm: k, ty for letting anastasiamac investigate
[01:18] <bradm> 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] <bradm> although why others aren't seeing it, I don't know.
[01:45] <mup> Bug #1579593 opened: SSH host keys for bootstrap aren't checked <security> <juju-core:New> <https://launchpad.net/bugs/1579593>
[01:54] <anastasiamac> is it still applicable with mongo3? https://bugs.launchpad.net/juju-core/+bug/1447390
[01:54] <mup> Bug #1447390: mongo tools missing on centos <centos> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1447390>
[02:21] <anastasiamac> wallyworld: perrito666: with fixes to backup and restore that u r focusing on,  has there been any movements in the related bugs?
[02:21] <anastasiamac> for e.g.:  https://bugs.launchpad.net/juju-core/+bug/1493458
[02:21] <mup> Bug #1493458: backups restore: fails when machine number differs <backup-restore> <docteam> <docteam-blocking> <ha> <juju-core:Triaged> <https://launchpad.net/bugs/1493458>
[02:22] <anastasiamac> and surely this is improving :D https://bugs.launchpad.net/juju-core/+bug/1545568
[02:22] <mup> Bug #1545568: api/backups/restore.go has no unit tests <backup-restore> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1545568>
[02:22] <anastasiamac> and this https://bugs.launchpad.net/juju-core/+bug/1545562
[02:22] <mup> Bug #1545562: Restore assumes systemd present on machines <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1545562>
[02:22] <wallyworld> the systemd one might be fixed
[02:23] <wallyworld> the machine number one is an old bug - may have been fixed incidentally
[02:23] <wallyworld> we'd really need to audit what's there once the current mongo 3.2 compatibility issues have been solved
[02:23] <anastasiamac> update in the bugs would b amazing, even if it's just a progress update
[02:23] <wallyworld> no one is actively working those bugs
[02:23] <wallyworld> i didn't even know they existed
[02:24] <anastasiamac> u do now \o/
[02:24] <wallyworld> we'll need to fix the current mongo 3.2 issues first
[02:25] <anastasiamac> 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] <anastasiamac> like surely we are putting *some* api tests in the area?..
[02:26] <wallyworld> no, because the api is not changing
[02:26] <wallyworld> we are fixing the backend implrementation
[02:27] <wallyworld> the scope of the current work is constrained to mongo 3.2 compatibility
[02:27] <wallyworld> 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] <wallyworld> it is hard enough to fix the mongo 3.2 issues without scope creep for addtional, unrelated bugs
[02:29] <wallyworld> we can add those to the bug board
[02:29] <wallyworld> they can be investigated in parallel with the current work, as they are not related
[02:29] <anastasiamac> m not saying "fix"... \o/
[02:30] <anastasiamac> m saying " u r in the area, have u encountered these?" so that we can determine if they r still current :D
[02:36] <wallyworld> 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] <wallyworld> ie we would not have a scenario where the machine nuimber differs, as we are restoring with the -b option
[02:37] <wallyworld> and testing todate has been on xenial (mongo 3.2), so systemd is always there
[02:39] <anastasiamac> thank you for update and clarification
[02:41] <wallyworld> sorry that there' been no activity in those other areas
[02:41] <anastasiamac> yes :D very disappointing :-P
[03:27] <anastasiamac> wallyworld: axw: i seem to recal that this has been addressed, non? https://bugs.launchpad.net/juju-core/+bug/1316874
[03:27] <mup> Bug #1316874: How to specify an environment to be specific series <config> <docs> <juju-core:Triaged> <https://launchpad.net/bugs/1316874>
[03:27] <mup> Bug #1494787 changed: bootstrap cannot be interrupted if machine agent fails to start <juju-core:Triaged> <https://launchpad.net/bugs/1494787>
[03:27] <mup> Bug #1510875 changed: unable to interrupt 'juju boostrap' on MAAS before the node is running <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1510875>
[03:27] <axw> anastasiamac: set-model-config default-series=...
[03:27] <wallyworld> and bootstrap-series arg for the controller
[03:28] <anastasiamac> axw:  this is about "juju bootstrap --series="
[03:28] <anastasiamac> hmm i guess bootstrap-series even
[03:28] <wallyworld> the first bug above talks about environment (model)
[03:28] <axw> anastasiamac: it's not? the issue is about the model series
[03:28] <axw> and that's what "default-series" is
[03:28] <wallyworld> yep
[03:29] <wallyworld> there's 2 series here - the model series and the controller series
[03:29] <anastasiamac> k.. axw: so old bug pre model/controller distinction :D
[03:30] <anastasiamac> both talk about "bootstrap" so probably intended artifacts are controllers
[03:30] <anastasiamac> to get a controller of particular series we use "juju bootstrap -bootstrap-series"?
[03:30] <axw> anastasiamac: yeah, at the time the bug was filed, there was no multi-model
[03:31] <anastasiamac> to get a model of particular series..?
[03:31] <axw> anastasiamac: correct
[03:31] <axw> 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] <anastasiamac> axw: so is there any means of overwritting default-series? what do u mean by "otherwise" specified?
[03:32] <axw> anastasiamac: "juju add-machine --series=..."
[03:35] <anastasiamac> 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] <axw> 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] <mup> Bug #1494787 opened: bootstrap cannot be interrupted if machine agent fails to start <juju-core:Triaged> <https://launchpad.net/bugs/1494787>
[03:36] <axw> anastasiamac: you can use the usual commands to get/set default-series in model config.
[03:36] <mup> Bug #1510875 opened: unable to interrupt 'juju boostrap' on MAAS before the node is running <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1510875>
[03:39] <mup> Bug #1494787 changed: bootstrap cannot be interrupted if machine agent fails to start <juju-core:Triaged> <https://launchpad.net/bugs/1494787>
[03:39] <mup> Bug #1510875 changed: unable to interrupt 'juju boostrap' on MAAS before the node is running <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1510875>
[03:39] <anastasiamac> axw: k - thnx \o/ . so to create a model in particular series "juju add-model --config default-series=..."
[03:39] <axw> yep
[03:48] <anastasiamac> axw: since u have mentioned "add-machine --series=..." any idea if this is fixed? https://bugs.launchpad.net/juju-core/+bug/1273216
[03:48] <mup> Bug #1273216: unknown --series to add-machine breaks provisioner <bitesize> <juju-core:Triaged> <https://launchpad.net/bugs/1273216>
[03:48] <axw> anastasiamac: no idea
[03:49] <anastasiamac> axw: k
[03:51] <mup> Bug #1316874 changed: How to specify an environment to be specific series <config> <docs> <juju-core:Fix Released> <https://launchpad.net/bugs/1316874>
[03:51] <mup> Bug #1317666 changed: bootstrap CLI should have an option to specify target series  (phase 2) <bootstrap> <feature> <hours> <juju-core:Fix Released by menno.smits> <https://launchpad.net/bugs/1317666>
[04:38] <anastasiamac> i think this is fixed https://bugs.launchpad.net/juju-core/+bug/1254402... anyone know any different?
[04:38] <mup> Bug #1254402: error bootstrapping on ec2 duplicate security group <ec2-provider> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1254402>
[04:42] <mup> Bug #1305279 changed: default-series is the only way to set the series of the state-server <bootstrap> <docs> <landscape> <micro-cluster> <trusty> <upload-tools> <juju-core:Fix Released> <https://launchpad.net/bugs/1305279>
[07:10] <mup> Bug #1579633 opened: state.leadershipClient used unsafely <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1579633>
[08:22] <mup> Bug #1537740 changed: sudo error on bootstrap and working on units <juju-release-support> <lxd-provider> <usability> <juju-core:Invalid> <https://launchpad.net/bugs/1537740>
[08:31] <mup> Bug #1537740 opened: sudo error on bootstrap and working on units <juju-release-support> <lxd-provider> <usability> <juju-core:Invalid> <https://launchpad.net/bugs/1537740>
[08:40] <mup> Bug #1537740 changed: sudo error on bootstrap and working on units <juju-release-support> <lxd-provider> <usability> <juju-core:Invalid> <https://launchpad.net/bugs/1537740>
[09:01] <voidspace> dimitern: frobware: be right there for standup - grabbing coffee!
[09:05] <voidspace> dimitern: hmmm, actually - frobware is away
[09:14] <voidspace> fwereade: dimitern: dooferlad: firefox crash!
[09:14] <voidspace> brb
[09:39] <voidspace> mgz: ping
[10:47] <voidspace> fwereade: ping
[10:48] <voidspace> 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] <voidspace> fwereade: is this expected behaviour - that if you use custom settings like this you need to "manually propagate" them to models
[10:51] <fwereade> voidspace, not that I am aware of... anastasiamac, wallyworld, thoughts on the above?
[10:52] <voidspace> fwereade: still need to confirm that's *really* the problem, but it seems to be what the logs are showing
[10:52] <wallyworld> voidspace: fwereade: correct, hosted models ony inherit a subset of properties from their controller admin model
[10:52] <wallyworld> this was from tim's original design
[10:52] <voidspace> wallyworld: including the default model immediately after bootstrap
[10:53] <wallyworld> yes
[10:53] <wallyworld> hosted models are their own thing
[10:53] <wallyworld> with their own attributes
[10:53] <voidspace> so you bootstrap with settings and immediately have to reapply those settings
[10:53] <voidspace> and DRY be damned :-)
[10:53] <wallyworld> depends on what your needs are
[10:53] <wallyworld> why should a hosted model be forced to get it's tools from the same place as the admin model
[10:54] <voidspace> sure, it's a nice design principle to make simple cases simple
[10:54] <wallyworld> anyways, that was the design (not mine)
[10:54] <voidspace> wallyworld: thanks for confirming
[10:54] <wallyworld> that's from memory - i'd have to double check to see
[10:54] <wallyworld> let me do that in case my memory is flawed
[10:55] <voidspace> it very much seems so from the logs we're seeing
[10:55] <voidspace> it's easy enough to work around now we know
[10:56] <fwereade> wallyworld, voidspace: I thought tools streams were meant to be per-controller though
[10:56] <wallyworld> voidspace: so there's a method on Environ called RestrictedConfigAttributes()
[10:56] <wallyworld> that defines attributes that need to be the same between models withon a controller
[10:56] <fwereade> 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] <wallyworld> fwereade: i don't know to be honest, what the original design constraints were
[10:58] <wallyworld> voidspace: fwereade: as implemented, these are shared
[10:58] <wallyworld> 		"type",
[10:58] <wallyworld> 		config.CACertKey,
[10:58] <wallyworld> 		"state-port",
[10:58] <wallyworld> 		"api-port",
[10:58] <wallyworld> 		config.ControllerUUIDKey,
[10:58] <wallyworld> plus provider specific restricted attributes
[10:59] <wallyworld> as far as i can tell from the code, the model uses its own valeus for everythign else
[10:59] <voidspace> wallyworld: thanks
[10:59] <wallyworld> but i'll dig a bit deeper
[10:59] <wallyworld> the above just restricts what can't be overridden
[11:03] <wallyworld> 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] <wallyworld> so agent stream or agent url is not inherited from what i can see
[11:04] <wallyworld> if that original design from way back when is wrong, then we can fix
[11:06] <voidspace> probably worth a discussion on juju-core, or an executive decision
[11:07] <ejat> http://paste.ubuntu.com/16316990/
[11:56] <voidspace> dimitern: a bunch of tests for AllocateContainerAddresses http://reviews.vapour.ws/r/4790/
[11:56] <dimitern> voidspace: looking
[11:56] <voidspace> dimitern: I still want to write tests for deviceInterfaceInfo2 as well
[12:02] <dimitern> 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] <dimitern> voidspace: but ofc ymmv
[12:05] <voidspace> dimitern: I'm only ever checking one stub at a time, and sharing would actually mean an extra line of code
[12:05] <voidspace> :-)
[12:05] <voidspace> arguably cleaner but arguably not
[12:05] <voidspace> dimitern: useful if I do need to do multiple checks - thanks
[12:05] <dimitern> voidspace: I can show you not very good examples of too much sharing done :)
[12:05] <voidspace> hehe
[12:06] <voidspace> I've tried to scope the tests to a single point
[12:06] <voidspace> so one interesting stub per test falls out of that
[12:06] <voidspace> although each test still needs all the setup for the previous test :-/
[12:07] <voidspace> and sharing the stubs would be a nuisance for the SetErrors call
[12:07] <dimitern> voidspace: how about splitting the setup steps in mini helpers, easy to compose
[12:07] <voidspace> dimitern: I thought about it - I could avoid *some* duplication
[12:08] <voidspace> however later tests modify the earlier setup stages too
[12:08] <voidspace> (more machines, more subnets, more interfaces etc)
[12:08] <voidspace> so wouldn't help as much as you'd hope
[12:09] <voidspace> dimitern: I have some more tests to write - and in the PR for that I can look at consolidation, ok?
[12:09] <dimitern> voidspace: well, you could have a subnet := makeFakeSubnet(3)...
[12:10] <voidspace> true enough
[12:10] <dimitern> voidspace: sounds good, I'll add some suggestions
[12:10] <voidspace> dimitern: thanks
[12:16] <dimitern> voidspace: reviewed
[12:21] <voidspace> dimitern: thanks
[12:42] <nottrobin> does anyone know if anyone's tried adding http/2 support into the apache2 charm?
[12:43] <mgz> voidspace: pretty sure the only reason the bundle deploy test fails on maas 2.0 is bug 1568895
[12:43] <mup> Bug #1568895: Cannot add MAAS-based LXD containers in 2.0beta4 on trusty <ci> <jujuqa> <lxd> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1568895>
[12:44] <mgz> at least that was the case start of last week, now it seems somewhat unhappy even with lxc containers
[12:44] <mgz> nottrobin: you're probably better off asking in #juju - but you can also see the various branches on launchpad
[12:47] <tvansteenburgh> 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] <nottrobin> 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] <mgz> tvansteenburgh: use godeps?
[12:51] <mgz> nottrobin: seems to be https://code.launchpad.net/charms/+source/apache2
[12:52] <nottrobin> mgz: thanks
[12:53] <mgz> nottrobin: there's also a trusty series link at the bottom with more
[12:53] <nottrobin> yeah I found that. thanks
[12:59] <tvansteenburgh> mgz thanks
[13:08] <mup> Bug #1579750 opened: Wrong hostname added to dnsmasq using LXD <juju-core:New> <https://launchpad.net/bugs/1579750>
[13:14] <voidspace> mgz: the error it fails with is "no matching tools" for machine 0
[13:15] <voidspace> mgz: which doesn't seem like a lxd container issue
[13:20] <mgz> voidspace: I don't see that, looking at maas-2.0-bundle-deploy
[13:25] <voidspace> mgz: http://reports.vapour.ws/releases/3955/job/maas-2_0-bundle-deploy/attempt/12
[13:25] <voidspace> mgz: machine "0", "no tools available"
[13:26] <voidspace> mgz: and the failure reason, "ErroredUnit: 0 is in state error"
[13:26] <voidspace> mgz: that's the latest run on master
[13:27] <voidspace> mgz: the other deploy-bundle tests succeeded
[13:29] <mgz> voidspace: hm, on that revision only. also, compare http://juju-ci.vapour.ws/job/maas-2_0-bundle-deploy/14/
[13:29] <mgz> same rev, only change, bundle with lxc containers not lxd
[13:30] <voidspace> mgz: 404
[13:31] <mgz> voidspace: login.
[13:31] <voidspace> mgz: I am logged in
[13:31] <voidspace> ah, not to that service maybe
[13:31] <mgz> voidspace: navigate to the job if I tyoped it. but you want the developer creds from cloud-city consoles.txt
[13:32] <mup> Bug #1579057 changed: Race in github.com/juju/juju/worker/catacomb/catacomb <blocker> <ci> <race-condition> <regression> <juju-core:Fix Released by fwereade> <https://launchpad.net/bugs/1579057>
[13:32] <mgz> it looks to me like 12 failed because the machines didn't come up cleanly
[13:32] <mgz> we don't have addresses for 0 or 1 in the non-admin model
[13:32] <mgz> so, the tools thing looks like a red herring
[13:32] <voidspace> mgz: what credentials do I use for juju-ci.vapour - it's not using SSO as far as I can see
[13:33] <voidspace> mgz: ah, thanks
[13:33] <voidspace> mgz: not sure if you tyoped it or not...
[13:42] <voidspace> mgz: if you look in logsink for 12 you do see it trying the "wrong address" for the tools for machine 0
[13:42] <voidspace> mgz: so I'm not convinced yet :-)
[13:42] <voidspace> mgz: you're likely to be right, I'm just not convinced yet...
[13:50] <mgz> voidspace: what went wrong on that job is an interesting question, but it's not been the main cause of failure
[14:02] <mup> Bug #1578286 changed: Juju2 cannot deploy windows workloads on maas 1.9  <blocker> <ci> <maas-provider> <regression> <windows> <juju-core:Fix Released by bteleaga> <https://launchpad.net/bugs/1578286>
[14:02] <mup> Bug #1579062 changed: localHTTPSServerSuite no trusty arm64/ppc64el images <arm64> <blocker> <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Fix Released by reedobrien> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1579062>
[15:01] <katco> natefinch: standup time
[15:13] <mgz> evilnick: is `juju help glossary` on your list of things to fix already? or should I file a bug?
[15:13] <mgz> oh, someone killed it already
[15:14] <evilnick> yes, it was me
[15:14] <mgz> evilnick: good job, it was terrible.
[15:14] <evilnick> mgz there is a 'concepts page' now
[15:14] <evilnick> it still nees work
[15:15] <mgz> evilnick: I have one other thing, our rackspace help currently references a temp bucket CI uses, which got nuked and recreated
[15:15] <mgz> 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] <mgz> but I could link my script/instructions for creating the image streams yourself instead
[15:16] <mgz> which is basically lp:juju-ci-tools rackspace-generate-image-streams.bash
[15:16] <mgz> or we could update to the new temp streams and hope it can just go away soon
[15:32] <evilnick> 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] <mgz> evilnick: that's fair enough
[15:33] <mgz> evilnick: I'm happy to put up a proposal with the new magic url for now
[15:33] <evilnick> mgz, I hope it will solve itself, but yes, any nonsense you want to add/subtract gratefully received
[15:59] <mup> Bug #1210593 changed: Show the user all current running environments <improvement> <juju-core:Fix Released> <https://launchpad.net/bugs/1210593>
[15:59] <mup> Bug #1240431 changed: Allow constraints to be set for only the bootstrap node <juju-core:Fix Released> <https://launchpad.net/bugs/1240431>
[16:02] <natefinch> trivial deps review anyone?  perrito666, katco, ericsnow: http://reviews.vapour.ws/r/4791/
[16:02] <mup> Bug #1210593 opened: Show the user all current running environments <improvement> <juju-core:Fix Released> <https://launchpad.net/bugs/1210593>
[16:02] <mup> Bug #1240431 opened: Allow constraints to be set for only the bootstrap node <juju-core:Fix Released> <https://launchpad.net/bugs/1240431>
[16:03] <perrito666> natefinch: looking
[16:03] <perrito666> natefinch: do you know what the systemd update enails?
[16:03] <perrito666> entails*
[16:05] <natefinch> 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] <natefinch> perrito666: both repos were over a year out of date
[16:06] <perrito666> natefinch: ship it
[16:06] <natefinch> perrito666: CI will catch breakages, right? :)
[16:06]  * perrito666 slaps natefinch in the back of the head
[16:06] <natefinch> perrito666: why even have CI if you can just throw things over the wall
[16:06] <natefinch> s/can/can't
[16:06]  * natefinch is sure it'll be fine.
[16:17] <mup> Bug #1210593 changed: Show the user all current running environments <improvement> <juju-core:Fix Released> <https://launchpad.net/bugs/1210593>
[16:17] <mup> Bug #1240431 changed: Allow constraints to be set for only the bootstrap node <juju-core:Fix Released> <https://launchpad.net/bugs/1240431>
[16:56] <alexisb> katco, ping
[17:00] <mup> Bug #1579833 opened: Initial admin cannot log out <doctem> <juju-core:New> <https://launchpad.net/bugs/1579833>
[17:00] <mup> Bug #1579836 opened: repeated login  attempt to websockets api results in confusing error message <landscape> <juju-core:New> <https://launchpad.net/bugs/1579836>
[17:06] <mup> Bug #1579833 changed: Initial admin cannot log out <doctem> <juju-core:New> <https://launchpad.net/bugs/1579833>
[17:06] <mup> Bug #1579836 changed: repeated login  attempt to websockets api results in confusing error message <landscape> <juju-core:New> <https://launchpad.net/bugs/1579836>
[17:09] <katco> alexisb: hey sorry was at lunch. pong
[17:17] <redir> do we support arm64 on 1.25?
[17:17] <mgz> redir: yup
[17:18] <mup> Bug #1579833 opened: Initial admin cannot log out <doctem> <juju-core:New> <https://launchpad.net/bugs/1579833>
[17:18] <mup> Bug #1579836 opened: repeated login  attempt to websockets api results in confusing error message <landscape> <juju-core:New> <https://launchpad.net/bugs/1579836>
[17:22] <redir> mmm
[17:24] <redir> mgz: is that new?
[17:25] <mgz> redir: nope, see history of arm64 tests on 1.25 branch, reports.vapour.ws/releases/3956 etc
[17:28] <redir> mgz: just seeing that it isn't in the supported arch test since 2014-08
[17:29] <redir> also used to test for an invalid arch constraint.
[17:29] <mgz> redir: the tests on arm64 may well had been broken for a while
[17:30] <mgz> the big switch is 1.25 was using gccgo for arm64, it's now go 1.6
[17:31] <redir> mgz: OK. Tx.
[17:34] <mgz> redir: see the history of some of our issues on arm64 tests, your bug 1579062 say, goes back all through wily
[17:34] <mup> Bug #1579062: localHTTPSServerSuite no trusty arm64/ppc64el images <arm64> <blocker> <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Fix Released by reedobrien> <juju-core 1.25:In Progress by reedobrien> <https://launchpad.net/bugs/1579062>
[18:04] <katco> does PatchValue not work on slices?
[18:05] <perrito666> katco: should work on any variable
[18:18] <mup> Bug #1579849 opened: Unclear what series a charm will use <docteam> <juju-core:New> <https://launchpad.net/bugs/1579849>
[18:34] <redir> quickie review anyone? http://reviews.vapour.ws/r/4792/
[18:35] <mgz> redir: yeah, s390x really is 2.0 only
[18:35] <mgz> redir: landit
[18:35]  * redir nods
[18:37] <mgz> check the bug is blocking first I guess
[18:37] <mgz> it should be
[19:18] <perrito666> aghh all the mongo tooling is written in go... except for the shell
[19:19] <perrito666> such is my luck
[19:23] <natefinch> perrito666: javascript not your favorite thing I take it? :)
[19:23] <perrito666> natefinch: C actually
[19:23] <perrito666> cpp
[19:23] <perrito666> natefinch: actually I was trying to fetch a mongo3 client and push it to my lxc container
[19:23] <natefinch> perrito666: oh
[19:23] <perrito666> and that is orders of magnitude easier in go
[19:24] <mup> Bug #1399613 changed: juju-core not using constraints when creating KVM  unit on maas machine <constraints> <kvm> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1399613>
[19:24] <mup> Bug #1534214 changed: Juju KVM container doesn't respect constraints <juju-core:Triaged> <https://launchpad.net/bugs/1534214>
[19:40] <perrito666> hey people, anyone remembers how to represent arrays using bson elements? more to the point, I need to represent this structure https://docs.mongodb.com/manual/reference/method/db.createRole/#db.createRole
[19:53] <natefinch> perrito666: pretty much anything you're creating should be a bson.M
[20:00] <natefinch> perrito666: something like this I think: http://pastebin.ubuntu.com/16324089/
[20:01] <natefinch> perrito666: except without the obvious typos
[20:16] <katco> perrito666: sorry, i immediately got pulled off on something. i'm running PatchValue on a slice and getting: "... Panic: reflect: call of reflect.Value.Elem on slice Value (PC=0x45F3CE)"
[20:17] <katco> perrito666: i don't think PatchValue will work on slices because of how it's performing reflection
[20:17] <natefinch> katco: gotta use &
[20:17] <katco> natefinch: sad trombone... thanks
[20:21] <mup> Bug #1579887 opened: Local charms not de-duped when deployed multiple times <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1579887>
[20:28] <natefinch> #@@#^^#$_()%@#_^#@()#@%*_(^_()^$_@^  te
[20:28] <natefinch> tests that run mongod
[20:28] <natefinch> $ ps -al |grep mongod | wc -l
[20:28] <natefinch> 9
[21:10] <perrito666> Katco what Nate said :p I assumed you had a ptr to it
[21:22]  * perrito666 just had to wait next to a school for someone and noticed that parents are willing to break any traffic rule to avoid walking one block
[21:30] <katco> perrito666: you can tell how highly i think of patchvalue ;p
[21:34] <perrito666> well I hate many things (patch value is high on that list) and those are the ones I try to learn the most, first because it makes so much easier to rant about them, and second because otherwise my frustration grows to unmanageable levels (but mostly for the rant value)
[21:45] <redir> sinzui: yt?
[21:46] <sinzui> redir: yes, in a meeting, will be free in about 15 minutes
[21:47] <redir> sinzui: k. lemme know when you're free
[22:02] <alexisb> thumper, going to be late
[22:02] <katco> wallyworld: stepping away for a sec
[22:03] <sinzui> hi redir
[22:03] <wallyworld> katco: sure, am talking to alexis forst
[22:03] <wallyworld> first
[22:03] <thumper> alexisb: ack
[22:08] <redir> sinzui: got a minute for a HO?
[22:09] <sinzui> redir: I do
[23:06] <menn0> thumper: juju/utils/ssh change that I need: https://github.com/juju/utils/pull/214
[23:09] <thumper> k
[23:15] <wallyworld> axw: anastasiamac: one minute late
[23:15] <anastasiamac> wallyworld: axwexcellent - gives me time to make a cuap \o/
[23:15] <anastasiamac> cup*
[23:18] <wallyworld> anastasiamac: we are all here when you are ready
[23:18] <thumper> menn0: review done
[23:19] <menn0> thumper: thanks
[23:19] <thumper> menn0: there wasn't something around the default value
[23:19] <thumper> which I think was No not Unset
[23:19] <thumper> perhaps another test is needed?
[23:20] <menn0> thumper: that's intentional... the current default is "no" so I didn't want to break that
[23:20] <thumper> so why have unset?
[23:20] <menn0> thumper: because that's what I need now
[23:20] <menn0> "no" and "unset" mean different things
[23:20] <menn0> "no" means "no"
[23:21] <thumper> ugh
[23:21] <menn0> "unset" means, "use whatever's in the user's config elsewhere"
[23:21] <menn0> that is, don't include a "-o StrictHostKeyChecking" option on the command line at all
[23:23] <menn0> thumper: is that ok? should I add a comment for the consts to explain the differences ?
[23:24] <thumper> so how do you say unset?
[23:24] <menn0> options.SetStrictHostKeyChecking(StrictHostKeyCheckingUnset)
[23:25] <anastasiamac> menn0: comments should be added regardless \o/
[23:25] <thumper> menn0: from the CLI
[23:25] <anastasiamac> menn0: should= would be vey helpful :-P
[23:26] <menn0> thumper: from the CLI, the user doesn't directly control that option
[23:26] <thumper> hmm
[23:26] <thumper> ok
[23:26] <thumper> add a comment
[23:27] <menn0> thumper: but juju ssh/scp will use unset when you do something like: juju ssh some.host
[23:27] <thumper> and we're good I expect
[23:27] <menn0> as opposed to juju ssh 2, or juju ssh unit/2
[23:27] <menn0> ok
[23:27] <menn0> anastasiamac, thumper: comments being added
[23:27]  * thumper runs into town to get some more USB sticks
[23:27] <thumper> because reasons