[00:09] <menn0> veebers: i'm able to replicate what you're seeing... still digging
[00:11] <menn0> veebers: ah ... now I see why
[00:12] <menn0> veebers: users connected to the controller using "juju register" have a macroon, not a password
[00:12] <anastasiamac> axw: wallyworld: this is on 1.25 with old azure... is may have troubles deploying to it and could become critical... is it easily fixed?  https://bugs.launchpad.net/juju-core/+bug/1459148
[00:12] <mup> Bug #1459148: azure: juju can't create compute/network optimized instances <add-machine> <azure-provider> <canonical-is> <constraints> <feature> <juju-core:Triaged> <https://launchpad.net/bugs/1459148>
[00:13] <menn0> veebers: the migration infrastructure doesn't support that
[00:13] <menn0> damn...
[00:15] <anastasiamac> axw: my pR has not landed. will consider a proper fix rather than a badage solution :D
[00:22] <veebers> menn0: hmm, so should I be doing something different or are we attempting to test something that isn't completely there?
[00:23] <menn0> veebers: you have uncovered a gaping hole in functionality :-/
[00:23] <veebers> ah ok, that's a result at least :-)
[00:23] <menn0> veebers: the way users are handled has changed a lot and migrations needs to be updated to work with it
[00:24] <menn0> veebers: better that we find this out now rather than later :)
[00:24] <veebers> heh yeah true that :-)
[00:24] <menn0> veebers: that'll be me for the rest of the day then
[00:25] <veebers> menn0: ok, let me know how you get on (or have a build you would like me to test.) I'll clean up this test and get it ready for review
[00:35] <anastasiamac> axw: the problem was me - reverted tests. should be all good now \o/
[00:57] <axw> anastasiamac: "The bug is reference in PR title. All you need to do is look it up."  <- I know it's there, and I know I can look it up. The usual pattern is to have it in the description, so I didn't see it to start with. Please do what's standard so it makes a reviewer's life easier.
[01:00] <axw> anastasiamac: if you wanted to go the extra mile, it would be even better to use a clickable link. not everyone does that, but it's more helpful than just a bug number
[01:02] <anastasiamac> axw: sure. however, each reviewer works differently. m happy to add bug link in pr - no need to stress on Monday :D
[01:02] <axw> anastasiamac: thank you
[01:03] <anastasiamac> axw: a rare pleasure. i'd rather have u smiling :)
[01:03] <anastasiamac> or at least content \o/
[01:05] <axw> anastasiamac wallyworld: assuming I can get chrome and my webcam to play nice, happy to chat whenever. what was it about? tools/image arch constraints?
[01:05] <blahdeblah_> wallyworld: anastasiamac tells me you are awesome for fixing bugs quickly. So thanks. :-)
[01:05] <anastasiamac> axw: wallyworld: yes and m not really stressing about but m happy to chat :)
[01:06] <wallyworld> blahdeblah_: i didn't know it was a bug, the need for it came up in another context
[01:06] <anastasiamac> wallyworld: u r too humble \o/
[01:06] <anastasiamac> wallyworld: u've fixed it and now must accept the title of "awesome" ;)
[01:07] <wallyworld> well if a 50 line bug fix is all it takes...
[01:07] <axw> wallyworld: it's a trap, they're trying to get you to stop doing feature work
[01:08] <wallyworld> i know right
[01:18] <blahdeblah_> features schmeatures
[01:18] <axw> menn0: sorry missed yor message before
[01:19] <menn0> axw: no worries
[01:19] <axw> menn0: well we have model status, shouldn't we be setting it when we're doing a migration?
[01:19] <menn0> axw: is this in the output of the show-model command?
[01:19] <axw> menn0: yes
[01:20] <menn0> axw: yep, we should show something there
[01:20] <menn0> axw: there will be a "migration" field under "status" with an info string
[01:20] <menn0> axw: but the "current" field should reflect the status too
[01:21] <menn0> axw: i'll be changing show-model soon so I'll make that change then as well
[01:21] <axw> menn0: cool, sounds good
[01:21] <menn0> axw: thanks, I just wanted to clarify that it you were talking about show-model and not something else
[01:23] <axw> wallyworld: FYI I have a fix that works for speeding up add-machine in azure, basically by not synchronising on the provisioning state for VMs
[01:23] <wallyworld> great ok
[01:23] <axw> wallyworld: doing this means we'll regress on a recent change though, you won't be able to see why provisioning fails when it does
[01:23] <wallyworld> yeah
[01:23] <anastasiamac> axw: m looking at bug 1567747 as I am in this area right now. do u have more info? what provider? what commands, especially flags and options were run? pastebin is no longer accessbile...
[01:23] <mup> Bug #1567747: "juju metadata generate-image" does not validate architectures <observability> <simplestreams> <ui> <juju-core:Triaged> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1567747>
[01:23] <axw> wallyworld: so I'm looking at whether we can easily get that info into the instance status
[01:24] <wallyworld> i think we'd be able to hopefully
[01:24] <axw> wallyworld: yeah just not sure about how much work is involved, whether we should defer till next beta
[01:24] <wallyworld> IMO having a fast deploy is more important
[01:24] <axw> anastasiamac: sorry, I don't know - pretty sure that pastebin came from the user
[01:25] <axw> anastasiamac: IIRC you just pass "-a x86_64" ?
[01:25] <axw> anastasiamac: which should fail, because x86_64 is not an arch we understand
[01:26] <anastasiamac> axw: k. tyvm
[01:35] <thumper> axw: do you have any examples of charms / deployment args I could use on lxd to test migration of storage constraints?
[01:37] <axw> thumper: here's a metadata.yaml that I use: http://paste.ubuntu.com/23077118/. create a charm dir with that, then use "juju deploy <path/to/charm> --storage filesystem=tmpfs,1G"
[01:37] <thumper> axw: awesome, ta
[01:50] <mup> Bug #1219582 changed: bootstrap lookups tools multiple times <canonistack> <performance> <simplestreams> <juju-core:Invalid> <https://launchpad.net/bugs/1219582>
[01:50] <mup> Bug #1237378 changed: "juju bootstrap --upload-tools" fails sometimes for ssl-hostname-verification: false <bootstrap> <simplestreams> <upload-tools> <juju-core:Invalid> <https://launchpad.net/bugs/1237378>
[01:56] <mup> Bug #1219582 opened: bootstrap lookups tools multiple times <canonistack> <performance> <simplestreams> <juju-core:Invalid> <https://launchpad.net/bugs/1219582>
[01:56] <mup> Bug #1237378 opened: "juju bootstrap --upload-tools" fails sometimes for ssl-hostname-verification: false <bootstrap> <simplestreams> <upload-tools> <juju-core:Invalid> <https://launchpad.net/bugs/1237378>
[01:59] <mup> Bug # changed: 1219582, 1237378, 1317680, 1345567, 1349691
[02:04] <axw> wallyworld: it looks like it's going to be a PITA to get the error message, so I'm thinking I'll propose as is and then address after. sound ok?
[02:04] <wallyworld> yup
[02:04] <axw> wallyworld: there's another approach we can take to provisioning as well, which will speed everything up further - and then the error messages can be got at
[02:04] <wallyworld> sgtm
[02:05] <mup> Bug #1317680 opened: can't juju add machine when multiple images with same arch/release exist <amd64> <apport-bug> <cloud-installer> <kvm> <simplestreams> <streams> <trusty> <juju-core:Fix Released> <juju-core (Ubuntu):Invalid> <https://launchpad.net/bugs/1317680>
[02:05] <mup> Bug #1345567 opened: problems bootstrapping aws due to s3 write errors when uploading tools <ec2-provider> <simplestreams> <upload-tools> <juju-core:Invalid> <https://launchpad.net/bugs/1345567>
[02:05] <mup> Bug #1349691 opened: support aws govcloud <ec2-provider> <simplestreams> <streams> <juju-core:Fix Released> <https://launchpad.net/bugs/1349691>
[02:14] <mup> Bug #1317680 changed: can't juju add machine when multiple images with same arch/release exist <amd64> <apport-bug> <cloud-installer> <kvm> <simplestreams> <streams> <trusty> <juju-core:Fix Released> <juju-core (Ubuntu):Invalid> <https://launchpad.net/bugs/1317680>
[02:14] <mup> Bug #1345567 changed: problems bootstrapping aws due to s3 write errors when uploading tools <ec2-provider> <simplestreams> <upload-tools> <juju-core:Invalid> <https://launchpad.net/bugs/1345567>
[02:14] <mup> Bug #1349691 changed: support aws govcloud <ec2-provider> <simplestreams> <streams> <juju-core:Fix Released> <https://launchpad.net/bugs/1349691>
[02:14] <thumper> car's ready, relocating back home
[02:14] <thumper> bbs
[02:20] <mup> Bug #1210482 changed: use simplestreams info for endpoint labels instead of specifying endpoints <simplestreams> <juju-core:Fix Released> <https://launchpad.net/bugs/1210482>
[02:20] <mup> Bug #1212173 changed: juju bootstrap searches for tools 2 times <bootstrap> <performance> <simplestreams> <juju-core:Triaged> <https://launchpad.net/bugs/1212173>
[02:20] <mup> Bug #1230367 changed: environs/simplestreams: could do with splitting <simplestreams> <tech-debt> <juju-core:Fix Released> <https://launchpad.net/bugs/1230367>
[02:22] <anastasiamac> wallyworld: plz update bug 1262175
[02:22] <mup> Bug #1262175: debate drop --upload-tools flag <jujuqa> <simplestreams> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1262175>
[02:22] <wallyworld> wow, that's an old one
[02:23] <wallyworld> sadly the bug is still valid
[02:23] <wallyworld> upload tools still exists and is used, it's just now implicit
[02:24] <wallyworld> so the complaint in the bug report is still there
[02:25] <wallyworld> and because people rely on it, and we now need it for snaps, it's probably here to stay
[02:25] <wallyworld> will have to discuss a bit before marking as invalid
[02:28] <anastasiamac> wallyworld: m not asking u to mark as invali. m asking u to update the bug with current view (like the work that you have done in the area last couple of weeks)
[02:32] <wallyworld> i think we'll just mark it as invalid, i just need to check will william. the work that's been done doesn't change anything that the bug says is "evil", all the functionality is still present in juju; the only thing different is that upload-tools flag is gone
[02:32] <wallyworld> i could update the bug title
[02:33] <wallyworld> done, that is now more accurate
[02:34] <veebers> where can I find docs on the --show-log argument?
[02:36] <wallyworld> not sure that there is any
[02:37] <veebers> oh ok, so --show-log puts all the logs to stdout? Nothing goes to stdin?
[02:45] <anastasiamac> axw: wallyworld: in ur recent work with credentials revamp, did u encounter/fixed scenarios with # in pwds?
[02:45] <anastasiamac> https://bugs.launchpad.net/juju-core/+bug/1567607
[02:45] <mup> Bug #1567607: vsphere bootstrap fails when environments.yaml has a password with the # character <bootstrap> <cdo-qa> <vsphere> <juju-core:Triaged> <https://launchpad.net/bugs/1567607>
[02:45] <axw> anastasiamac: no
[02:46] <wallyworld> ino from me too
[02:46] <wallyworld> didn't realise we had that issue
[02:46] <anastasiamac> axw: wallyworld: k. thnx
[02:46] <wallyworld> veebers: --show-log pritns to stdout what would normally not be seen because it goes to a log sink rather than stdou
[02:49] <thumper> menn0: back, and in hangout
[02:49] <menn0> thumper: ok, hang on
[02:49] <veebers> wallyworld: with --show-log used are errors still spat out to stderr or is everything now out to stdout via the logs (which include normal and error messages etc.)
[02:50] <wallyworld> errors should still go to stderr
[02:50] <veebers> (I of course meant stderr not stdin beforehand :-\)
[02:50] <wallyworld> the only change IIANM is that we show additonal output
[02:50] <mup> Bug #1400971 changed: all agents except machine agent logging "INFO juju.worker.upgrader upgrader.go:121 desired tool version: 1.18.4.3" every 15 minutes following
[02:50] <mup> "juju upgrade-juju" <prodstack> <simplestreams> <upgrade-juju> <upload-tools> <juju-core:Invalid> <juju-core 1.18:Won't Fix> <https://launchpad.net/bugs/1400971>
[02:50] <mup> Bug #1457068 changed: bootstrap failed, no tools available <simplestreams> <ui> <juju-core:Won't Fix> <https://launchpad.net/bugs/1457068>
[02:50] <veebers> wallyworld: cool thanks
[02:57] <veebers> wallyworld: seems --show-log outputs the logs to stderr, is this expected behaviour? (i.e. juju --show-log status --help 2>>out.err 1>>out.std && cat out.err)
[02:57] <wallyworld> yes
[02:57] <wallyworld> you don't want to sully stdout with it
[02:58] <veebers> ack, fair enough
[02:58] <wallyworld> people might need to parse stdout yaml or whatever
[02:58] <veebers> yeah that's a very good ponint
[02:59] <mup> Bug #1242476 changed: Bootstrap fails with --upload-tools on private openstack cloud <bootstrap> <canonical-is> <canonical-webops> <openstack-provider> <simplestreams> <upload-tools> <juju-core:Fix Released> <https://launchpad.net/bugs/1242476>
[03:08] <mup> Bug #1242476 opened: Bootstrap fails with --upload-tools on private openstack cloud <bootstrap> <canonical-is> <canonical-webops> <openstack-provider> <simplestreams> <upload-tools> <juju-core:Fix Released> <https://launchpad.net/bugs/1242476>
[03:09] <thumper> veebers: logs generally go to stderr, except when you use the command debug-log, when they go to stdout
[03:09] <veebers> thumper: ack thanks.
[03:20] <mup> Bug #1242476 changed: Bootstrap fails with --upload-tools on private openstack cloud <bootstrap> <canonical-is> <canonical-webops> <openstack-provider> <simplestreams> <upload-tools> <juju-core:Fix Released> <https://launchpad.net/bugs/1242476>
[03:29] <wallyworld> thumper: i got 2 PRs up, you able to do your OCR duties :-)
[03:29] <thumper> yep
[03:30] <wallyworld> \o/
[03:38] <thumper> FFS
[03:38] <thumper> grr
[03:38] <thumper> $ juju dump-model
[03:38] <thumper> ERROR facade "ModelManager" not supported for model API connection (not supported)
[03:38] <thumper> someone broke dump-model
[03:39] <thumper> why limit it?
[03:39] <thumper> FFS
[03:40] <axw> thumper: can you please review http://reviews.vapour.ws/r/5492/ if you haven't already
[03:40] <axw> if you aren't*
[03:40] <thumper> ack
[03:40] <wallyworld> thumper: thanks for reviews
[03:41] <wallyworld> thumper: rog made that change, they need to separate controller vs model facades for jaas
[03:41] <wallyworld> it was explained in an email last week
[03:41] <wallyworld> or the week before maybe
[03:41] <wallyworld> ironically, it also broke their gui and metrics
[03:41] <thumper> I recall it coming up
[03:41] <thumper> but just frustrated
[03:43] <veebers> thumper: if you file a bug for the dump-model issue you just saw can you tag it EDA and link me to the bug please?
[03:44] <thumper> EDA?
[03:45] <veebers> thumper: Escaped Defect Analysis. Means we'll (qa) have a meeting discussing bugs/defects/issues that could have or should have been caught by testing
[03:45] <veebers> i.e why did this get through the net
[03:50] <mup> Bug #1219123 changed: Azure provider: Juju unable to locate any image when "image-stream: released" is set (doesn't validate content of image-stream) <azure-provider> <papercut> <juju-core:Invalid> <https://launchpad.net/bugs/1219123>
[03:52] <anastasiamac> thumper: m not sure why this failed to land... https://github.com/juju/juju/pull/5289 shall i try again?
[03:55] <thumper> anastasiamac: no, it needs a tweak
[03:55] <thumper> and I need to ask sinzui what the tweak is
[03:56] <anastasiamac> thumper: \o/
[03:56] <anastasiamac> thumper: there are also 2 Jesse's MADE PRs.. they seem to want a rebase :)
[03:56] <thumper> yes, I know
[04:20] <mup> Bug #1588897 changed: Unable to kill or destroy the lxd controller <destroy-controller> <lxd-provider> <juju-core:Expired> <https://launchpad.net/bugs/1588897>
[04:20] <mup> Bug #1591939 changed: juju failed unmarshal the /server/{server_id} api  response body <juju-core:Expired> <https://launchpad.net/bugs/1591939>
[04:20] <mup> Bug #1593303 changed: Google Compute Engine provider often reports wrong IP address as the public address <juju-core:Expired> <https://launchpad.net/bugs/1593303>
[07:52] <voidspace> has anyone managed to go back to lxd 2.0.0 on Wily after 2.1 landed in the stable PPA?
[08:37] <babbageclunk> Is anyone working on bug 1614559? I've got a fix for it if not, but I haven't proposed it because I still can't bootstrap.
[08:37] <mup> Bug #1614559: Juju rejects lxd 2.1 <bootstrap> <ci> <jujuqa> <lxd> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1614559>
[08:38] <babbageclunk> (So I guess not totally a fix)
[08:39] <babbageclunk> I get "ERROR failed to bootstrap model: cannot start bootstrap instance: unable to get LXD image for ubuntu-xenial: The requested image couldn't be found."
[08:39] <babbageclunk> Which is weird because I can lxc launch a xenial instance fine.
[08:39] <babbageclunk> dimitern: ^^
[08:40] <dimitern> babbageclunk: I'm looking at the code to see where's that version check
[08:40] <dimitern> babbageclunk: do you know how to get lxd 2.1 ?
[08:41] <babbageclunk> dimitern: It was just on this loaner laptop I'm using.
[08:41] <babbageclunk> I think you can just update?
[08:41] <dimitern> babbageclunk: is it running yakkety?
[08:42] <dimitern> babbageclunk: nope, on xenial at least I see these options: launch a xenial instance fine.
 dimitern: ^^
[08:42] <dimitern> [#juju-dev] oops not that
[08:42] <dimitern> babbageclunk: http://paste.ubuntu.com/23077711/
[08:42] <babbageclunk> dimitern: no, it's xenial
[08:44] <dimitern> babbageclunk: ok I did `sudo add-apt-repository ppa:ubuntu-lxc/lxd-stable` and now I see lxd 2.1 as available
[08:44] <babbageclunk> dimitern: I think this is using the lxd ppa
[08:44] <babbageclunk> dimitern: yeah, that would do it.
[08:45] <babbageclunk> dimitern: https://github.com/juju/juju/compare/master...babbageclunk:lxd-version?expand=1
[08:45] <babbageclunk> dimitern: That's where it does the version check, but I don't think my error's around there.
[08:46] <dimitern> babbageclunk: I'll try that, but I don't think this is the real fix
[08:46] <dimitern> babbageclunk: we should be checking the lxd api version to be 1.0, not the lxc cli version
[08:46] <babbageclunk> dimitern: Well, it fixes the bad logic in the version checking.
[08:46] <babbageclunk> dimitern: oh, sure.
[08:47] <babbageclunk> dimitern: really I just hacked something up so I can bootstrap.
[08:47] <babbageclunk> dimitern: (but I can't).
[08:53] <dimitern> babbageclunk: sure :)
[08:56] <babbageclunk> dimitern, fwereade: could you have a look at this? https://github.com/juju/juju/pull/6042
[08:56] <dimitern> babbageclunk: to just fix bootstrapping, why not try to comment the if !isSupportedLxdVersion() check in tools/lxdclient/client.go ?
[08:57] <babbageclunk> dimitern: I did better than that - I made the check right for 2.1. (Although checking the API version is better still.) But then something else still fails.
[08:57] <axw> dimitern: hey, don't suppose you had any time to look at the neutron APIs?
[08:58] <dimitern> axw: not yet :/ when do we need to know/reply about that?
[08:58] <axw> dimitern: (completely unrelated) in general, do you know if cloud-init should be writing /etc/network/interfaces.d/50-cloud-init.cfg with all NICs of a cloud VM? I've created a VM in Azure with 2 NICs, and it's only got a stanza for eth0
[08:59] <axw> dimitern: ASAP, but if you don't have time I can have a stab
[09:01] <dimitern> axw: we're taking the defaults for any cloud apart from maas - there we disable cloud-init's /e/n/i generation explicitly, so we don't get the fallback 50-cloud-init.cfg to mess up our statically configured /e/n/i
[09:02] <dimitern> axw: If you can, I'd appreciate it! I'll can have a look if something else could be needed for spaces support
[09:02] <axw> dimitern: yeah, just wondering if you know what I should expect from cloud-init's default behaviour. can't find any docs on this bit
[09:02] <axw> dimitern: ok, I was specifically asking about what's needed for spaces though :)
[09:02] <axw> dimitern: I'll have a look tomorrow
[09:02] <dimitern> axw: the default behaviour is to get a fallback dhcp eth0 from cl-in
[09:03] <axw> dimitern: only eth0, even if there's multiple NICs?
[09:03] <dimitern> axw: for spaces we need basically 2 things at minimum - listing subnets of a network, and deploying to a subnet
[09:04] <dimitern> axw: yeah - it's "designed" to be the fallback case when we don't known anything else
[09:07] <babbageclunk> dimitern, fwereade: also this? http://reviews.vapour.ws/r/5495/
[09:07] <dimitern> babbageclunk: I managed to bootstrap with lxd 2.1 and this quick-n-dirty patch: http://paste.ubuntu.com/23077748/
[09:08] <dimitern> babbageclunk: looking
[09:08] <fwereade> babbageclunk, former LGTM
[09:09] <natefinch> jam: good morning
[09:10] <voidspace> anyway to get reviewboard to notice PRs created when it was down?
[09:10] <voidspace> short of re-creating the PR
[09:10] <jam> hi natefinch. brt
[09:10] <jam> natefinch: https://hangouts.google.com/hangouts/_/canonical.com/john-meinel-nat
[09:10] <natefinch> jam: cool.  https://hangouts.google.com/hangouts/_/canonical.com/moonstone?authuser=1
[09:10] <natefinch> ha
[09:10] <natefinch> I'll go to yours
[09:10] <babbageclunk> fwereade: thanks!
[09:11] <jam> tag
[09:11] <dimitern> babbageclunk: LGTM on your ealier PR as well
[09:11] <jam> ok. I'm in mine. I'll wait a bit longer.
[09:11] <babbageclunk> dimitern: Also thanks! Hmm - I wonder what's going on with my lxd then?
[09:12] <dimitern> babbageclunk: what do you get as errors?
[09:13] <voidspace> lxd being screwed is a real downer
[09:13] <dimitern> babbageclunk: ok, sorry - my bootstrap appears to be still going and logging errors in c-i-output.log
[09:13] <babbageclunk> dimitern: I get "ERROR failed to bootstrap model: cannot start bootstrap instance: unable to get LXD image for ubuntu-xenial: The requested image couldn't be found."
[09:13] <voidspace> and in trying to revert to lxd 2.0 in xenial I've managed to screw lxd totally it seems
[09:13] <babbageclunk> voidspace: oh no
[09:13] <dimitern> babbageclunk: ah, that's different - try lxc image copy ubuntu:16.04 --alias ubuntu-xenial local:
[09:14] <voidspace> babbageclunk: heh, yeah
[09:14] <voidspace> babbageclunk: trying a purge and re-install of 2.1 to at least get back to a "just juju and lxd is screwed" situation
[09:14] <babbageclunk> dimitern: ahh, thanks. Why haven't I needed to do that before?
[09:14] <voidspace> restarting
[09:14] <voidspace> o/
[09:15] <fwereade> babbageclunk, I'm a bit twitchy about AllMachineRemovals being []model => []machine (rather than [][]machine -- I think of them as an array of requests). did my brain completely skate over that in the apiserver review?
[09:15] <dimitern> babbageclunk: not sure - but I've seen this months ago and that's how I fixed it (it was needed for trusty as well)
[09:17] <babbageclunk> fwereade: I think it did, yeah. :( I can see why you say that now though.
[09:17] <dimitern> babbageclunk: the errors preventing my lxd bootstrap were due to "no space left on device" for my zfs pool
[09:17] <mup> Bug #1615552 opened: Juju 2: Cannot add new key to default model config. <juju-core:New> <https://launchpad.net/bugs/1615552>
[09:17] <babbageclunk> dimitern: ha, yeah I've seen that before.
[09:17] <babbageclunk> dimitern: thanks, seems to be working now.
[09:19] <voidspace> yay, back to "normally screwed" instead of termially screwed
[09:21] <babbageclunk> fwereade: By which I mean I don't think you mentioned that (I'll check now). I can change it though.
[09:21] <fwereade> babbageclunk, sorry :(
[09:23] <dimitern> katco: are you working on bug 1614559 ?
[09:23] <mup> Bug #1614559: Juju rejects lxd 2.1 <bootstrap> <ci> <jujuqa> <lxd> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1614559>
[09:23] <dimitern> katco: the card's assigned to you, but the bug to rick_h_ ..
[09:24] <dimitern> katco: figured out how to fix it, and I'll take it over, if you don't mind
[09:24] <voidspace> dimitern: katco talked about it at standup on Friday - not sure if she's started it though
[09:24] <voidspace> dimitern: ah, hah
[09:24] <voidspace> dimitern: I doubt she'll mind you doing it
[09:24] <dimitern> ;) ok
[09:24] <voidspace> dimitern: you might even finish before I succeed in deploying a bundle to aws!! :-) (slooooow)
[09:25] <dimitern> basically we need to bump the lxd shared library version we're using to stable-2.0 and check the APIVersion field of server status, not its binary version
[09:25] <dimitern> voidspace: ;) let's see
[09:25] <voidspace> dimitern: yep
[09:26] <voidspace> dimitern: rick_h_ said he wanted an option (like a force option) to attempt to use a more recent version of the api than the one we expect
[09:26] <voidspace> dimitern: current api version is 1.0 I believe
[09:26] <dimitern> voidspace: that would've been ok, if we actually checked the api version :)
[09:26] <voidspace> dimitern: we need to work with lxd 2.0 still though as well as 2.1
[09:26] <voidspace> sure
[09:32] <mup> Bug #1615552 changed: Juju 2: Cannot add new key to default model config. <juju-core:New> <https://launchpad.net/bugs/1615552>
[09:35] <mup> Bug #1615552 opened: Juju 2: Cannot add new key to default model config. <juju-core:New> <https://launchpad.net/bugs/1615552>
[10:05] <babbageclunk> dimitern: now when I bootstrap jujud won't start in the container - it says unable to connect to: 10.82.88.1:8443 - any ideas?
[10:14] <dimitern> babbageclunk: here's my fix - I'd appreciate a review and a QA on it - see if it fixes the issue?
[10:14] <dimitern> voidspace: ^^
[10:14] <dimitern> http://reviews.vapour.ws/r/5496/
[10:15] <voidspace> dimitern: looking
[10:15] <babbageclunk> dimitern: also looking
[10:16] <dimitern> thanks guys!
[10:19] <voidspace> dimitern: hmmm... I can't checkout your branch
[10:19] <voidspace> dimitern: I can checkout your master but not lp-1614559-lxd-api-version
[10:19] <voidspace> weird
[10:19] <dimitern> voidspace: do you have my remote added?
[10:19] <voidspace> dimitern: yep :-)
[10:20] <dimitern> voidspace: try `git remote -v update`
[10:20] <dimitern> voidspace: and then checkout
[10:20] <voidspace> dimitern: I think I just need a fetch --all
[10:21] <voidspace> yep
[10:21] <voidspace> doh
[10:21] <voidspace> sorry
[10:21] <dimitern> voidspace: ;) np
[10:25] <voidspace> dimitern: works for me
[10:25] <frobware> dimitern: I commented on your PR. the changes break packaging.
[10:25] <voidspace> dimitern: just trying again as I didn't specify build-agent, however that doesn't matter as it works
[10:25] <frobware> dimitern: I know this as I had to revert my changes that used the shared.Devices form of Init()
[10:26] <dimitern> voidspace: cheers!
[10:26] <dimitern> frobware: can you clarify please?
[10:26] <voidspace> someone with lxd 2.0 should check it still works with this as well
[10:26] <frobware> dimitern: HO?
[10:26] <dimitern> frobware: ok, joining standup now
[10:30] <frobware> dimitern: http://pastebin.ubuntu.com/23078034/
[10:35] <babbageclunk> dimitern: That works for me but then I get the same error - unable to connect to 10.82.88.1:8443
[10:43] <voidspace> frobware: have you created a bot to add "in-progress" tags to PRs?
[10:43] <frobware> voidspace: nope
[10:44] <frobware> voidspace: were you expecting me to?
[10:44] <voidspace> frobware: https://github.com/juju/juju/pull/6055
[10:44] <voidspace> frobware: an in progress label appeared within seconds of me creating the PR!
[10:44] <mup> Bug #1615580 opened: logging emits inappropriate ANSI escape codes on non-ANSI terminal <juju-core:New for thumper> <https://launchpad.net/bugs/1615580>
[10:49] <babbageclunk> fwereade: so, I'll make AllMachineRemovals return a params.EntitiesResults, which has Results which is []params.Entities?
[10:51] <babbageclunk> fwereade: does that mean that WatchMachineRemovals should also return a NotifyWatchResults (instead of a NotifyWatchResult as it does now) for the same reason?
[10:51] <babbageclunk> fwereade: Hmm, I guess that doesn't actually need to - it can be one watcher which notifies when any of the things change, right?
[10:53] <dimitern> babbageclunk: are you sure lxd is listening on that address? lxc config show ?
[10:54] <babbageclunk> dimitern: That just shows "core.https_address: '[::]'"
[10:54] <babbageclunk> dimitern: does that mean it's only listening on ipv6?
[10:55] <dimitern> babbageclunk: and what's your lxd-bridge config? /etc/default/lxd-bridge
[10:55] <dimitern> babbageclunk: no, it should listen on both
[10:55] <menn0> frobware: what's with the "in progress" label?
[10:56] <frobware> menn0: why is everybody asking me this?
[10:56] <frobware> menn0, voidspace: there's a disconnect here. I don't know anything about this label.
[10:56] <babbageclunk> frobware: Why'd you tag my PR in-progress?
[10:56] <frobware> babbageclunk: ^^
[10:56] <babbageclunk> dimitern: http://paste.ubuntu.com/23078076/
[10:56] <menn0> frobware: I just created a new PR and within seconds you apparently added a label to the PR. looks like something automated that's using your credentials or something.
[10:56] <babbageclunk> frobware: :)
[10:57] <babbageclunk> frobware's been haxxored.
[10:57] <menn0> frobware: see here: https://github.com/juju/juju/pull/6056
[10:57] <frobware> menn0: ah, crap. I have an idea.
[10:58]  * menn0 hears a distant penny dropping
[11:00] <frobware> menn0, voidspace, babbageclunk: apologies. I was playing with waffle.io this morning, took the dog for a walk, then forget I had integrated that into my github account. oops.
[11:00]  * babbageclunk can't work out why all these brooms keep bringing more water in!
[11:00] <dimitern> babbageclunk: for good measure, I'd re-run sudo dpkg-reconfigure -p medium lxd
[11:00] <dimitern> babbageclunk: and just take the current settings
[11:01] <menn0> frobware: that'll be it then :)
[11:01] <frobware> menn0: yep, sorry for the noise. :(
[11:01] <dimitern> babbageclunk: that seems to help sometimes with partially screwed up lxd bridge config
[11:01] <menn0> frobware: no harm done
[11:01] <frobware> menn0: I revoked access to juju/juju on my account for waffle.io
[11:04] <babbageclunk> dimitern: Aha, that's something - at the end of the reconfigure there's an error restarting lxd
[11:05] <dimitern> babbageclunk: there you go :) what's the error?
[11:06] <babbageclunk> dimitern: http://paste.ubuntu.com/23078092/
[11:06] <babbageclunk> dimitern: might be time for a reboot
[11:07] <dimitern> babbageclunk: do you have srw-rw----  1 root lxd            0 Aug 22 10:15 unix.socket in /var/lib/lxd ?
[11:08] <babbageclunk> dimitern: yup
[11:09] <dimitern> babbageclunk: lxc info ?
[11:10] <fwereade> babbageclunk, hell sorry
[11:10] <babbageclunk> dimitern: connection refused - presumably that's because it failed to restart after the reconfigure.
[11:10] <fwereade> babbageclunk, I think both really ought to be multiple, shouldn't they?
[11:11] <dimitern> babbageclunk: anything in /var/log/syslog re lxd-bridge ?
[11:11] <babbageclunk> fwereade: I could see it either way in terms of the watcher.
[11:13] <fwereade> babbageclunk, I would follow the common.AgentEntityWatcher model, I think
[11:13] <babbageclunk> dimitern: lots of "lxd-bridge.service: Start request repeated too quickly." - scrolling back to see if there's a different error at the start.
[11:13] <fwereade> babbageclunk, at least NotifyWatchResults already exists
[11:14] <babbageclunk> fwereade: ok - makes sense. It all ends up the same on the client side, for now.
[11:14] <babbageclunk> fwereade: True. :)
[11:15] <fwereade> babbageclunk, cheers
[11:17] <babbageclunk> dimitern: Lots of this: http://paste.ubuntu.com/23078109/
[11:17] <dimitern> babbageclunk: I see - network manager gets in the way
[11:18] <dimitern> babbageclunk: or maybe not .. still looking
[11:19] <dimitern> babbageclunk: what's your `sudo iptables-save` content?
[11:20] <dimitern> babbageclunk: it looks like iptables rules lxd-bridge tries to add are duplicated or clash somehow
[11:22] <babbageclunk> dimitern: http://paste.ubuntu.com/23078114/
[11:23] <dimitern> babbageclunk: ufw it is then!
[11:24] <babbageclunk> dimitern: huh>
[11:24] <babbageclunk> ?
[11:24]  * babbageclunk is lost.
[11:24] <dimitern> babbageclunk: ufw is the so-called "uncomplicated firewall"
[11:25] <dimitern> babbageclunk: with seems to be eager to take over most of your iptables with custom rules for chains that are missing (e.g. ufw-before-forward)
[11:25] <babbageclunk> dimitern: So it's got some config that's stopping lxd-bridge from listening on port 8443?
[11:27] <dimitern> babbageclunk: try this - set ENABLED=no in /etc/ufw/ufw.conf and then systemctl restart ufw.service
[11:27] <dimitern> babbageclunk: it's trying to firewall off most things, including lxd-bridge
[11:28] <dimitern> babbageclunk: you can either configure ufw to allow specific traffic, or (better IMO) just disable ufw
[11:32] <dimitern> babbageclunk: sorry, so the ufw custom chains are there, but the default policy seems to be DROP, not ACCEPT - hence the issues, disabling ufw should clean up the output of iptables-save and let you lxd-bridge to start ok
[11:32] <babbageclunk> dimitern: ok, ufw is now "active (exited)"
[11:32] <dimitern> babbageclunk: good - mine shows the same
[11:32] <babbageclunk> dimitern: but restarting lxd-containers still isn't working. Hang on, checking syslog
[11:33] <dimitern> babbageclunk: restart lxd-bridge.service instead
[11:33] <dimitern> babbageclunk: lxd-containers seems to rely on the former
[11:34] <babbageclunk> dimitern: ah, ok
[11:35] <babbageclunk> dimitern: No, still see lots of "Bad rule (does a matching rule exist in that chain?)." in `systemctl status lxd-bridge.service`
[11:36] <babbageclunk> dimitern: to be precise: http://paste.ubuntu.com/23078151/
[11:37] <dimitern> babbageclunk: reviewed your second PR btw
[11:37] <babbageclunk> dimitern: Thanks
[11:38] <dimitern> babbageclunk: I'd try reconfiguring lxd again, but picking another subnet, e.g. 10.0.40.0/24 - it might be getting confused by the IP range you used
[11:38] <babbageclunk> dimitern: Is it possible that the rules ufw set up are still lurking in iptables?
[11:38] <babbageclunk> dimitern: ok, will try that.
[11:38] <dimitern> babbageclunk: grep sudo iptables-save for ufw
[11:40] <babbageclunk> dimitern: yeah, still lots of them
[11:40] <babbageclunk> dimitern: reconfiguring didn't help
[11:40] <dimitern> babbageclunk: so it ufw didn't remove its rules :/ I guess a reboot should fix it
[11:41] <babbageclunk> dimitern: w00t!
[11:41] <babbageclunk> dimitern: see you in a bit. Thanks for all the help!
[11:41] <dimitern> np, hope it helps ;)
[11:44]  * dimitern steps out for ~30m
[11:45]  * babbageclunk goes to grab some lunch and post some shorts.
[11:57] <natefinch> fwereade: an idea I had on friday when it seemed likely we were compiling with the wrong version of go in some places in CI: http://reviews.vapour.ws/r/5499/diff/#
[12:01] <fwereade> natefinch, nice! LGTM
[12:02] <natefinch> fwereade: :D
[12:06]  * dimitern is back
[12:10] <dimitern> mgz: ping
[12:10] <rick_h_> dimitern: yea, the bug is meant to be grabbed from me to the dev working on it
[12:10] <rick_h_> dimitern: that just indicates I've claimed the bug for my team vs alexis's
[12:10] <dimitern> rick_h_: I see - good to know, ok :)
[12:11] <dimitern> rick_h_: it was easy to fix, but frobware has some concerns mgz raised earlier re packaging
[12:11] <rick_h_> dimitern: yea, you'll see a bunch of bugs assigned to me, and they line up with the cards in the todo lane
[12:11] <rick_h_> dimitern: how so? is this in the backlog?
[12:11] <mup> Bug #1615601 opened: 2.0 beta 14 + openstack: generated hostnames exceed 255 byte limit <juju-core:New> <https://launchpad.net/bugs/1615601>
[12:12] <dimitern> rick_h_: no, from a chat they had in london, as frobware changed something similar to my fix
[12:12] <rick_h_> dimitern: oh interesting. Ok, let me know if we want to talk it through or something then
[12:13] <frobware> rick_h_, dimitern: I don't believe we should land the change until we have chatted with mgz
[12:13] <dimitern> rick_h_: let's raise it up at standup I guess
[12:13] <rick_h_> frobware: rgr
[12:13] <rick_h_> mgz: ping around?
[12:22] <rick_h_> frobware: dimitern you two have time to chat on networking/Y?
[12:22] <frobware> rick_h_: yep, would appreciate doing so now so I can go grab some lunch....
[12:22] <rick_h_> frobware: k, meet you in the standup room
[12:22] <dimitern> rick_h_: omw as well
[13:02] <mup> Bug #1615552 changed: Juju 2: Cannot add new key to default model config. <juju-core:Invalid> <https://launchpad.net/bugs/1615552>
[13:37] <frobware> rick_h_, dimitern: for reference https://bugs.launchpad.net/juju-core/+bug/1597342 regarding LXD deps bump
[13:37] <mup> Bug #1597342: Juju 2 is using a LXD API that is not in the released version of LXD 2.0 <juju-core:Fix Released by frobware> <https://launchpad.net/bugs/1597342>
[13:38] <frobware> rick_h_, dimitern: and the PR - https://github.com/juju/juju/pull/5769
[13:38] <dimitern> frobware: looking
[13:53] <babbageclunk> No alexisb today?
[13:54] <babbageclunk> I thought she was back from "horsing around".
[13:55] <anastasiamac> babbageclunk: it may be still a bit early for her :)
[13:56] <babbageclunk> anastasiamac: That's probably why she normally leaves her camera off.
[13:56] <anastasiamac> babbageclunk: maybe :D
[13:57] <voidspace> fwereade: ping
[13:57] <voidspace> fwereade: will you have some bandwidth tomorrow to talk about bug 1534103
[13:57] <mup> Bug #1534103: "unknown operation kind run-action" (1.26alpha3) <2.0-count> <actions> <sts> <juju-core:Triaged by rharding> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1534103>
[13:57] <voidspace> fwereade: IRC will be fine if you're still badwidth-ly challenged
[13:58] <anastasiamac> fwereade: did wallyworld ping u for bug 1262175? do we have any further comments?
[13:58] <mup> Bug #1262175: debate drop tools upload capability <jujuqa> <simplestreams> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1262175>
[14:01] <rick_h_> dimitern: fwereade macgreagoir ping for standup
[14:01] <voidspace> macgreagoir: you have a review by the way
[14:06] <natefinch> sinzui: where did we land with the 1.25 landing bot using go 1.6?  THe makefile seems to install the "golang" package, but I have no idea what that installs on various systems.  I wish we could be more explicit in our dependency on a specific version of Go.
[14:07] <natefinch> cc mgz ^^
[14:08] <sinzui> natefinch: I repeat the bot ues GO 1.6 and has since April 10
[14:08] <sinzui> natefinch: If juju's makefile is correct, it will also use go 1.6
[14:10] <natefinch> sinzui: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8853/artifact/artifacts/trusty-out.log    output from go version: go version go1.2.1 linux/amd64
[14:10] <sinzui> natefinch: Unit tests are runing according to how the branch states they run. The essential comands are: make install-dependencies; make build; make check
[14:12] <sinzui> natefinch: again, the 1.25 branch's makefile needs updating to match the engineering intent.
[14:12] <sinzui> natefinch: update you branch, and then your work and everyone elses will test with the right version of go
[14:14] <fwereade> voidspace, sorry! I would be happy to talk about it now in fact
[14:15] <voidspace> fwereade: I'm nearly EOD and going to the gym
[14:15] <fwereade> voidspace, ack, np, tomorrow is fine then :)
[14:15] <voidspace> fwereade: if you're around later I'll be back online
[14:15] <voidspace> kk
[14:15] <fwereade> voidspace, might be, but with family, so relatively unlikely
[14:15] <voidspace> fwereade: ok, cool
[14:15] <fwereade> anastasiamac, I don't think so
[14:15] <natefinch> sinzui: are people going to have a heart attack if I just explicitly curl the right version of go from golang.org?  Because that's really the only way we can ensure things don't change out from underneath us.
[14:16] <sinzui> natefinch: you cannot curl because that wont work on canonical machines
[14:16] <fwereade> anastasiamac, I am generally in favour -- but it all depends on the experience of self-publishing them, right?
[14:16] <sinzui> natefinch: go1.6 a deb packge ready to be installed
[14:17] <sinzui> natefinch: follow the example of the master Marefile
[14:17] <natefinch> sinzui: ahh, yeah, ok.
[14:18] <sinzui> natefinch: master is doing this: https://pastebin.canonical.com/163656/
[14:18] <voidspace> katco: http://reviews.vapour.ws/r/5497/
[14:19] <voidspace> katco: it's little :-)
[14:19] <katco> voidspace: yeah already looking at it :)
[14:19] <voidspace> great
[14:19] <katco> voidspace: you mentioned that there are existing tests, but how do we qa that the bug is actually fixed?
[14:19] <sinzui> natefinch: though I think the gccgo clause cannot ever be reeasched
[14:19] <natefinch> sinzui: I sure hope not, because it won't work
[14:19] <voidspace> katco: that's a question we haven't been able to answer for any of the places we've fixed this bug
[14:20] <katco> voidspace: ah bc it's based on load?
[14:20] <voidspace> katco: we can't deterministically trigger the mongo behaviour
[14:20] <voidspace> katco: yep
[14:20] <katco> gotcha
[14:20] <katco> fair enough
[14:21] <voidspace> mongo turns a bson.D into a bson.M (I think that's the right way round) and our assert becomes order dependent
[14:22] <katco> yeah that whole thing =|
[14:22] <katco> voidspace: ok, lgtm. ship it
[14:22] <katco> voidspace: sorry i didn't find this fri.
[14:22] <natefinch> sinzui: should I add bzip2 to the deps?  master has that for some reason
[14:22] <sinzui> natefinch: that wont hurt
[14:23] <voidspace> katco: thanks
[14:24] <sinzui> natefinch: in vaguely recall there is a  missing package for race testing in master's makefile. I am not sure how to handle that case if the package is not the same in all series
[14:24] <anastasiamac> fwereade: awesome! tyvm :D
[14:26] <natefinch> sinzui: should we update our list of supported architectures in 1.25 then also?
[14:26] <natefinch> sinzui: like, just the list in the makefile
[14:26] <sinzui> natefinch: absolutely. It's driven by the golang goodness
[14:26] <natefinch> ok
[14:27] <sinzui> natefinch: we officially don't support s390x with 1.x, but is does build and appear to work
[14:33] <natefinch> sinzui: mind if I change the no-gopath check to an error?  Seems like if you're ever running the makefile, you really must have a GOPATH
[14:34] <sinzui> natefinch: +1
[14:40] <frobware> voidspace: when the nodes don't commission using my scripts does it eventually error with "error: maas19-node7 did not reach 'shut off' state after 240s"?
[14:41] <natefinch> sinzui: http://reviews.vapour.ws/r/5503/
[14:43] <voidspace> frobware: didn't try with maas 1.9  - don't recall any error like that
[14:43] <voidspace> frobware: I'm just off now, can try later if you like
[14:44] <frobware> voidspace: don't worry
[14:46] <sinzui> natefinch: LGTM
[14:47] <natefinch> sinzui: thanks
[14:55] <dimitern> rick_h_, frobware: I've updated http://reviews.vapour.ws/r/5496/ to allow unsupported versions, but log a warning as suggested
[15:00] <mup> Bug #1615013 opened: Autopilot: Nagios uses the wrong subnet IP to reach one host <landscape> <juju-core:New> <Landscape Server:Invalid> <MAAS:New> <nagios (Juju Charms Collection):New> <https://launchpad.net/bugs/1615013>
[15:01]  * natefinch adds files that aren't even compiled.... CI fails :/
[15:02] <natefinch> (not because of my files, just flaky tests on windows)
[15:07] <natefinch> rick_h_: oh, btw, talked to john, he ok'd the use of the go-jsschema package I was using, as long as we also remove the use of the gojsonschema package we've been using (which is fine, it's only used in a couple files, and should be less than a dozen lines of code to change, all told).
[15:22] <natefinch> sinzui, mgz: how hard is it to set up https://github.com/juju/jsonschema with the landing bot?  All it really needs to do is run go get github.com/juju/jsonschema && go test github.com/juju/jsonschema
[15:24] <mgz> natefinch: it's pretty easy
[15:24] <rick_h_> natefinch: <3
[15:25] <natefinch> mgz: when you get some time, please and thank yuo.
[15:25] <mgz> natefinch: sure thing
[15:26] <mgz> natefinch: branch currently just has a licence?
[15:26] <natefinch> mgz: I can't land the PR with the code without a bot to land it :)
[15:26] <mgz> natefinch: okay :)
[15:26] <dimitern> mgz: hey there ;)
[15:27] <dimitern> mgz: did you see my ping earlier?
[15:27] <mgz> ah, I see, it already has bots over hackers in ther perms
[15:27] <mgz> dimitern: no, sorry, only just around now
[15:27] <mgz> dimitern: how can I help
[15:27] <mgz> hm, interesting dep version issue of some kind?
[15:28] <mgz> lets have a look at the lxd code
[15:29] <mgz> dimitern: what did you need the bump for?
[15:29] <sra__> can anyone provide me the better requirements for deploying openStack on a single VM using JUJU OpenStack-base bundle
[15:30] <dimitern> mgz: well, frobware and you had some chat about packaging issue wrt lxd and juju
[15:30] <dimitern> mgz: see http://reviews.vapour.ws/r/5496/
[15:30] <mgz> dimitern: our main issue is that because lxd is in the archive, even api compatible code changes to lxd can cause issues, if the 'abi' has changed,
[15:31] <mgz> so, for example,
[15:32] <mgz> we update a dep to a new version that has an extra field in a struct - which is normally fine
[15:32] <mgz> however, when we backport that juju code, it is then building against the older version of the dep without that field, and breaks
[15:32] <mgz> so, the fix would be sru the dep at the same time,
[15:33] <dimitern> ok, but that seems unsolvable
[15:33] <dimitern> catch 22
[15:33] <mgz> but, if *anything else at all* uses that dep, we risk then breaking the other way, as those projects could expect something different at compile time
[15:33] <dimitern> juju-core does not depend on lxd AFAICS (packaging-wise)
[15:33] <mgz> we build against it
[15:34]  * dimitern is still confused what's the right call here
[15:34] <mgz> anyway, the specifics matter here, we may be okay
[15:36] <mgz> dimitern: I don't see how we do this other than by taking the change, and as needed, dropping our build dep on the archive
[15:36] <mgz> it's what we had to do before
[15:37] <mgz> it means we build with a smaller and smaller set of packaged deps as things update
[15:37] <mgz> but snaps sort of avoid all this anyway
[15:38] <mgz> and that's where we're going
[15:38] <mgz> dimitern: I'll comment on the mp
[15:39] <dimitern> mgz: cheers!
[15:40] <mgz> dimitern: from the diff, it's not totally clear to me, did you need the lxdDevices arg? or did you update just because?
[15:41] <dimitern> mgz: it was needed after bumping lxc/lxd's revision, Init() now takes devices
[15:43] <mgz> dimitern: when I last looked that change wasn't on stable-2.0 branch
[15:44] <dimitern> mgz: it still isn't
[15:44] <frobware> dimitern: and did we need to bump as far as we did for this change?
[15:44] <mgz> is the change you actually need on that branch?
[15:45] <dimitern> frobware: this is the commit that is needed: https://github.com/lxc/lxd/commit/0d172e3080f768fd419f0c97f5246983797db243
[15:46] <frobware> dimitern: oh, 10 days ago... :(
[15:46] <mgz> so, we flat out depend on lxd 2.1 then...
[15:47] <dimitern> yeah, so if it's so recent I thought bumping to tip of lxc/lxd master shouldn't be a big deal
[15:48] <dimitern> mgz: if we need to cut it exactly, 2.0.4 will work
[15:48] <dimitern> mgz: https://github.com/lxc/lxd/commit/1a6adb0332e8f1da761cf899a92f9b8d8af53268
[15:49] <frobware> mgz, dimitern: wouldn't 2.0.4 be better here
[15:49] <mgz> yeah, I think while we can
[15:50] <mgz> we should stick on that branch
[15:50] <frobware> agreed
[15:50] <frobware> 2.1 would invalidate all the testing we've done
[15:50] <babbageclunk> fwereade: Take another look at http://reviews.vapour.ws/r/5495/? The types should be more to your liking now.
[15:51] <fwereade> babbageclunk, ta
[15:51] <mgz> this isn't a panacea for the basic problem of 'abi' compat, but does keep what we test and expect to work more consitent at least
[15:53] <dimitern> mgz, frobware: updated the PR to use 2.0.4's rev# and just pushed the change
[15:55] <mgz> dimitern: thanks! does that build? reviewboard only shows me the depedencies.tsv change for the interdiff
[15:55] <frobware> dimitern: how did Init(...with... devices) end up in 2.0.4?
[15:56] <frobware> dimitern: isn't that a breaking API change on 2.0?
[15:56] <dimitern> mgz: it builds and works - redid my live bootstrap
[15:56] <dimitern> frobware: I don't know, but it's there
[15:56] <dimitern> frobware: it's a breaking ABI change more than an API change :)
[15:57] <dimitern> well, both I guess
[15:57] <dimitern> one of those oops moments - sh*t we forgot to report the API version!
[15:57] <mgz> yeah, the terms don't quite map to go
[16:01] <redir> morning
[16:04] <katco> morning redir
[16:04] <redir> :)
[16:12] <mup> Bug #1615719 opened: [juju-2.0-beta15] during the bootstrap stage the no-proxy config is ignored <openstack-provider> <juju-core:New> <https://launchpad.net/bugs/1615719>
[16:16] <fwereade> babbageclunk, reviewed
[16:16]  * fwereade out for a while, back for thumper meeting this evening
[16:16] <babbageclunk> fwereade: thanks!
[16:23] <dimitern> rick_h_, frobware, mgz: I'll leave http://reviews.vapour.ws/r/5496/ and we should decide tomorrow for sure whether to land it or not
[16:23] <frobware> dimitern: ack
[18:23] <redir> brb system wants reboot
[19:31]  * rick_h_ goes to get the boy from school, biab
[21:38] <menn0> veebers: I have the changes ready for review which add macaroon support for migrations. once that lands you should be able to proceed with the authentication tests
[21:38] <menn0> thumper: http://reviews.vapour.ws/r/5498/
[21:39] <thumper> dev?
[21:39] <thumper> in bootstrap
[21:39] <thumper> lxd?
[21:39] <menn0> thumper: after a helpful chat with rogpeppe last night, i'm going to improve the way macaroons are used with migrations but this PR is good enough for now and lets veebers press on with CI tests
[21:39] <thumper> ok
[21:40] <thumper> menn0: on the release call just now
[21:40] <veebers> menn0: cool, cheers :-)
[21:40] <rogpeppe> thumper: did you see this bug BTW? https://bugs.launchpad.net/juju-core/+bug/1615580
[21:40] <mup> Bug #1615580: logging emits inappropriate ANSI escape codes on non-ANSI terminal <juju-core:New for thumper> <https://launchpad.net/bugs/1615580>
[21:40] <menn0> thumper: yep, dev is my lxd cloud with all the right options set
[21:40] <rogpeppe> thumper: (hi, BTW!)
[21:41] <thumper> o/ rogpeppe
[21:41] <thumper> rogpeppe: I'll make term = dumb work
[21:41] <rogpeppe> thumper: thanks
[21:41]  * menn0 needs to update the wiki with the latest config advice
[21:41] <rogpeppe> thumper: really i think it should be anything except term=ansi, but i guess not many people use non-ansi ttys any more :)
[21:42] <rogpeppe> thumper: strictly speaking you should be parsing termcap/terminfo
[21:42] <thumper> $ env | grep TERM
[21:42] <thumper> TERM=xterm-256color
[21:42] <thumper> rogpeppe: it makes a syscall to determin whether a terminal or not
[21:43] <thumper> and it is someone else's package
[21:43] <rogpeppe> thumper: yeah, but that says nothing about what escape codes it supports
[21:43] <thumper> but where we are using it, we can check for particulars
[21:43] <rogpeppe> thumper: tbh i'm not sure it's great to be adding this stuff as a dep to juju
[21:44] <rogpeppe> thumper: couldn't we just colourize post-hoc if desired?
[21:44] <thumper> some people desire color
[21:44] <thumper> I can understand that some don't like it, but they are definitely a minority
[21:45] <rogpeppe> thumper: i just see all the trivial deps we're adding to anything that imports juju/cmd
[21:45] <thumper> it has been specifically asked for by sabdfl
[21:46] <rogpeppe> thumper: fair enough. doesn't necessarily mean it needs to built in at quite such a low level though, i think.
[21:55] <mup> Bug #1597601 opened: ERROR cannot deploy bundle: cannot deploy application: i/o timeout <2.0> <bundles> <deploy> <oil> <oil-2.0> <repeatability> <retry> <juju-core:New for thumper> <https://launchpad.net/bugs/1597601>
[22:02]  * rick_h_ runs for the day
[22:06] <redir> Have a good evening rick_h_
[22:25] <mup> Bug #1615839 opened: Manual-provider claims s390x is not supported <ci> <manual-provider> <regression> <s390x> <juju-core:Triaged> <https://launchpad.net/bugs/1615839>
[22:55] <mup> Bug # changed: 918386, 1227942, 1358219, 1453096, 1470820, 1473197, 1473466, 1476060, 1477357, 1479194, 1483672, 1486965, 1488139, 1490480, 1491353, 1492237, 1493458, 1493598, 1493600, 1493601, 1493604, 1493606, 1494661, 1495978, 1496159, 1497351, 1498235, 1499900, 1500298, 1503990, 1510689,
[22:55] <mup> 1513466, 1516669, 1516676, 1520373, 1524171, 1532670
[23:10] <mup> Bug # changed: 1534923, 1536461, 1536480, 1539216, 1547665, 1552815, 1557918, 1566545, 1568160, 1569106, 1574076, 1574773, 1575764, 1581878, 1582105, 1590143, 1592887, 1598291, 1598292, 1602508, 1610397, 1613516, 1613823, 1613864
[23:16] <axw> wallyworld: cam is still playing up, will join soon
[23:16] <wallyworld> ok
[23:17] <wallyworld> thumper: alexisb standup?
[23:19] <mup> Bug # opened: 1534923, 1536461, 1536480, 1539216, 1547665, 1552815, 1557918, 1566545, 1568160, 1569106, 1574076, 1574773, 1575764, 1581878, 1582105, 1590143, 1592887, 1598291, 1598292, 1602508, 1610397, 1613516, 1613823, 1613864
[23:19] <perrito666> wallyworld: you dropped
[23:25] <mup> Bug # changed: 802117, 1386425, 1445174, 1454059, 1490789, 1501709, 1510133, 1534923, 1536461, 1536480, 1539190, 1539216, 1547665, 1552815, 1554120, 1557918, 1563705, 1566545, 1568160, 1569106, 1570269, 1570285, 1574076, 1574773, 1575764, 1576700, 1577598, 1581878, 1582105, 1590143, 1590598,
[23:25] <mup> 1590821, 1590961, 1592887, 1598291, 1598292, 1602508, 1609643, 1610397, 1613516, 1613823, 1613864, 1614072, 1615013
[23:43] <alexisb> thumper, can you rejoin please
[23:43] <thumper> anastasiamac: hello on call reviewer
[23:43] <thumper> anastasiamac: http://pastebin.ubuntu.com/23077491/
[23:44] <anastasiamac> thumper: want me to review a pastebin? :D
[23:49]  * thumper sighs
[23:49] <thumper> anastasiamac: http://reviews.vapour.ws/r/5505/
[23:49] <thumper> wrong thing in the buffer
[23:49] <anastasiamac> thumper: looking
[23:51] <alexisb> wallyworld, free when you are
[23:51] <wallyworld> ok, joining standup
[23:55] <menn0> thumper: http://reviews.vapour.ws/r/5498/ if you have a chance
[23:56] <thumper> menn0: ok