[00:09] veebers: i'm able to replicate what you're seeing... still digging [00:11] veebers: ah ... now I see why [00:12] veebers: users connected to the controller using "juju register" have a macroon, not a password [00:12] 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] Bug #1459148: azure: juju can't create compute/network optimized instances

[00:13] veebers: the migration infrastructure doesn't support that [00:13] damn... [00:15] axw: my pR has not landed. will consider a proper fix rather than a badage solution :D [00:22] menn0: hmm, so should I be doing something different or are we attempting to test something that isn't completely there? [00:23] veebers: you have uncovered a gaping hole in functionality :-/ [00:23] ah ok, that's a result at least :-) [00:23] veebers: the way users are handled has changed a lot and migrations needs to be updated to work with it [00:24] veebers: better that we find this out now rather than later :) [00:24] heh yeah true that :-) [00:24] veebers: that'll be me for the rest of the day then [00:25] 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] axw: the problem was me - reverted tests. should be all good now \o/ [00:57] 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] 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] axw: sure. however, each reviewer works differently. m happy to add bug link in pr - no need to stress on Monday :D [01:02] anastasiamac: thank you [01:03] axw: a rare pleasure. i'd rather have u smiling :) [01:03] or at least content \o/ [01:05] 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] wallyworld: anastasiamac tells me you are awesome for fixing bugs quickly. So thanks. :-) [01:05] axw: wallyworld: yes and m not really stressing about but m happy to chat :) [01:06] blahdeblah_: i didn't know it was a bug, the need for it came up in another context [01:06] wallyworld: u r too humble \o/ [01:06] wallyworld: u've fixed it and now must accept the title of "awesome" ;) [01:07] well if a 50 line bug fix is all it takes... [01:07] wallyworld: it's a trap, they're trying to get you to stop doing feature work [01:08] i know right [01:18] features schmeatures [01:18] menn0: sorry missed yor message before [01:19] axw: no worries [01:19] menn0: well we have model status, shouldn't we be setting it when we're doing a migration? [01:19] axw: is this in the output of the show-model command? [01:19] menn0: yes [01:20] axw: yep, we should show something there [01:20] axw: there will be a "migration" field under "status" with an info string [01:20] axw: but the "current" field should reflect the status too [01:21] axw: i'll be changing show-model soon so I'll make that change then as well [01:21] menn0: cool, sounds good [01:21] axw: thanks, I just wanted to clarify that it you were talking about show-model and not something else [01:23] 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] great ok [01:23] 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] yeah [01:23] 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] Bug #1567747: "juju metadata generate-image" does not validate architectures

[01:23] wallyworld: so I'm looking at whether we can easily get that info into the instance status [01:24] i think we'd be able to hopefully [01:24] wallyworld: yeah just not sure about how much work is involved, whether we should defer till next beta [01:24] IMO having a fast deploy is more important [01:24] anastasiamac: sorry, I don't know - pretty sure that pastebin came from the user [01:25] anastasiamac: IIRC you just pass "-a x86_64" ? [01:25] anastasiamac: which should fail, because x86_64 is not an arch we understand [01:26] axw: k. tyvm [01:35] axw: do you have any examples of charms / deployment args I could use on lxd to test migration of storage constraints? [01:37] thumper: here's a metadata.yaml that I use: http://paste.ubuntu.com/23077118/. create a charm dir with that, then use "juju deploy --storage filesystem=tmpfs,1G" [01:37] axw: awesome, ta [01:50] Bug #1219582 changed: bootstrap lookups tools multiple times

[01:50] Bug #1237378 changed: "juju bootstrap --upload-tools" fails sometimes for ssl-hostname-verification: false

[01:56] Bug #1219582 opened: bootstrap lookups tools multiple times

[01:56] Bug #1237378 opened: "juju bootstrap --upload-tools" fails sometimes for ssl-hostname-verification: false

[01:59] Bug # changed: 1219582, 1237378, 1317680, 1345567, 1349691 [02:04] 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] yup [02:04] 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] sgtm [02:05] Bug #1317680 opened: can't juju add machine when multiple images with same arch/release exist

[02:05] Bug #1345567 opened: problems bootstrapping aws due to s3 write errors when uploading tools

[02:05] Bug #1349691 opened: support aws govcloud

[02:14] Bug #1317680 changed: can't juju add machine when multiple images with same arch/release exist

[02:14] Bug #1345567 changed: problems bootstrapping aws due to s3 write errors when uploading tools

[02:14] Bug #1349691 changed: support aws govcloud

[02:14] car's ready, relocating back home [02:14] bbs [02:20] Bug #1210482 changed: use simplestreams info for endpoint labels instead of specifying endpoints

[02:20] Bug #1212173 changed: juju bootstrap searches for tools 2 times

[02:20] Bug #1230367 changed: environs/simplestreams: could do with splitting

[02:22] wallyworld: plz update bug 1262175 [02:22] Bug #1262175: debate drop --upload-tools flag

[02:22] wow, that's an old one [02:23] sadly the bug is still valid [02:23] upload tools still exists and is used, it's just now implicit [02:24] so the complaint in the bug report is still there [02:25] and because people rely on it, and we now need it for snaps, it's probably here to stay [02:25] will have to discuss a bit before marking as invalid [02:28] 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] 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] i could update the bug title [02:33] done, that is now more accurate [02:34] where can I find docs on the --show-log argument? [02:36] not sure that there is any [02:37] oh ok, so --show-log puts all the logs to stdout? Nothing goes to stdin? [02:45] axw: wallyworld: in ur recent work with credentials revamp, did u encounter/fixed scenarios with # in pwds? [02:45] https://bugs.launchpad.net/juju-core/+bug/1567607 [02:45] Bug #1567607: vsphere bootstrap fails when environments.yaml has a password with the # character

[02:45] anastasiamac: no [02:46] ino from me too [02:46] didn't realise we had that issue [02:46] axw: wallyworld: k. thnx [02:46] veebers: --show-log pritns to stdout what would normally not be seen because it goes to a log sink rather than stdou [02:49] menn0: back, and in hangout [02:49] thumper: ok, hang on [02:49] 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] errors should still go to stderr [02:50] (I of course meant stderr not stdin beforehand :-\) [02:50] the only change IIANM is that we show additonal output [02:50] 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] "juju upgrade-juju"

[02:50] Bug #1457068 changed: bootstrap failed, no tools available

[02:50] wallyworld: cool thanks [02:57] 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] yes [02:57] you don't want to sully stdout with it [02:58] ack, fair enough [02:58] people might need to parse stdout yaml or whatever [02:58] yeah that's a very good ponint [02:59] Bug #1242476 changed: Bootstrap fails with --upload-tools on private openstack cloud

[03:08] Bug #1242476 opened: Bootstrap fails with --upload-tools on private openstack cloud

[03:09] veebers: logs generally go to stderr, except when you use the command debug-log, when they go to stdout [03:09] thumper: ack thanks. [03:20] Bug #1242476 changed: Bootstrap fails with --upload-tools on private openstack cloud

[03:29] thumper: i got 2 PRs up, you able to do your OCR duties :-) [03:29] yep [03:30] \o/ [03:38] FFS [03:38] grr [03:38] $ juju dump-model [03:38] ERROR facade "ModelManager" not supported for model API connection (not supported) [03:38] someone broke dump-model [03:39] why limit it? [03:39] FFS [03:40] thumper: can you please review http://reviews.vapour.ws/r/5492/ if you haven't already [03:40] if you aren't* [03:40] ack [03:40] thumper: thanks for reviews [03:41] thumper: rog made that change, they need to separate controller vs model facades for jaas [03:41] it was explained in an email last week [03:41] or the week before maybe [03:41] ironically, it also broke their gui and metrics [03:41] I recall it coming up [03:41] but just frustrated [03:43] 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] EDA? [03:45] 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] i.e why did this get through the net [03:50] Bug #1219123 changed: Azure provider: Juju unable to locate any image when "image-stream: released" is set (doesn't validate content of image-stream)

[03:52] thumper: m not sure why this failed to land... https://github.com/juju/juju/pull/5289 shall i try again? [03:55] anastasiamac: no, it needs a tweak [03:55] and I need to ask sinzui what the tweak is [03:56] thumper: \o/ [03:56] thumper: there are also 2 Jesse's MADE PRs.. they seem to want a rebase :) [03:56] yes, I know [04:20] Bug #1588897 changed: Unable to kill or destroy the lxd controller

[04:20] Bug #1591939 changed: juju failed unmarshal the /server/{server_id} api response body [04:20] Bug #1593303 changed: Google Compute Engine provider often reports wrong IP address as the public address === gnuoy` is now known as gnuoy === frankban|afk is now known as frankban [07:52] has anyone managed to go back to lxd 2.0.0 on Wily after 2.1 landed in the stable PPA? [08:37] 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] Bug #1614559: Juju rejects lxd 2.1

[08:38] (So I guess not totally a fix) [08:39] 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] Which is weird because I can lxc launch a xenial instance fine. [08:39] dimitern: ^^ [08:40] babbageclunk: I'm looking at the code to see where's that version check [08:40] babbageclunk: do you know how to get lxd 2.1 ? [08:41] dimitern: It was just on this loaner laptop I'm using. [08:41] I think you can just update? [08:41] babbageclunk: is it running yakkety? [08:42] babbageclunk: nope, on xenial at least I see these options: launch a xenial instance fine. [08:42] dimitern: ^^ [08:42] [#juju-dev] oops not that [08:42] babbageclunk: http://paste.ubuntu.com/23077711/ [08:42] dimitern: no, it's xenial [08:44] babbageclunk: ok I did `sudo add-apt-repository ppa:ubuntu-lxc/lxd-stable` and now I see lxd 2.1 as available [08:44] dimitern: I think this is using the lxd ppa [08:44] dimitern: yeah, that would do it. [08:45] dimitern: https://github.com/juju/juju/compare/master...babbageclunk:lxd-version?expand=1 [08:45] dimitern: That's where it does the version check, but I don't think my error's around there. [08:46] babbageclunk: I'll try that, but I don't think this is the real fix [08:46] babbageclunk: we should be checking the lxd api version to be 1.0, not the lxc cli version [08:46] dimitern: Well, it fixes the bad logic in the version checking. [08:46] dimitern: oh, sure. [08:47] dimitern: really I just hacked something up so I can bootstrap. [08:47] dimitern: (but I can't). [08:53] babbageclunk: sure :) [08:56] dimitern, fwereade: could you have a look at this? https://github.com/juju/juju/pull/6042 [08:56] babbageclunk: to just fix bootstrapping, why not try to comment the if !isSupportedLxdVersion() check in tools/lxdclient/client.go ? [08:57] 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] dimitern: hey, don't suppose you had any time to look at the neutron APIs? [08:58] axw: not yet :/ when do we need to know/reply about that? [08:58] 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] dimitern: ASAP, but if you don't have time I can have a stab [09:01] 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] 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] 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] dimitern: ok, I was specifically asking about what's needed for spaces though :) [09:02] dimitern: I'll have a look tomorrow [09:02] axw: the default behaviour is to get a fallback dhcp eth0 from cl-in [09:03] dimitern: only eth0, even if there's multiple NICs? [09:03] axw: for spaces we need basically 2 things at minimum - listing subnets of a network, and deploying to a subnet [09:04] axw: yeah - it's "designed" to be the fallback case when we don't known anything else [09:07] dimitern, fwereade: also this? http://reviews.vapour.ws/r/5495/ [09:07] babbageclunk: I managed to bootstrap with lxd 2.1 and this quick-n-dirty patch: http://paste.ubuntu.com/23077748/ [09:08] babbageclunk: looking [09:08] babbageclunk, former LGTM [09:09] jam: good morning [09:10] anyway to get reviewboard to notice PRs created when it was down? [09:10] short of re-creating the PR [09:10] hi natefinch. brt [09:10] natefinch: https://hangouts.google.com/hangouts/_/canonical.com/john-meinel-nat [09:10] jam: cool. https://hangouts.google.com/hangouts/_/canonical.com/moonstone?authuser=1 [09:10] ha [09:10] I'll go to yours [09:10] fwereade: thanks! [09:11] tag [09:11] babbageclunk: LGTM on your ealier PR as well [09:11] ok. I'm in mine. I'll wait a bit longer. [09:11] dimitern: Also thanks! Hmm - I wonder what's going on with my lxd then? [09:12] babbageclunk: what do you get as errors? [09:13] lxd being screwed is a real downer [09:13] babbageclunk: ok, sorry - my bootstrap appears to be still going and logging errors in c-i-output.log [09:13] 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] and in trying to revert to lxd 2.0 in xenial I've managed to screw lxd totally it seems [09:13] voidspace: oh no [09:13] babbageclunk: ah, that's different - try lxc image copy ubuntu:16.04 --alias ubuntu-xenial local: [09:14] babbageclunk: heh, yeah [09:14] 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] dimitern: ahh, thanks. Why haven't I needed to do that before? [09:14] restarting [09:14] o/ [09:15] 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] 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] fwereade: I think it did, yeah. :( I can see why you say that now though. [09:17] babbageclunk: the errors preventing my lxd bootstrap were due to "no space left on device" for my zfs pool [09:17] Bug #1615552 opened: Juju 2: Cannot add new key to default model config. [09:17] dimitern: ha, yeah I've seen that before. [09:17] dimitern: thanks, seems to be working now. [09:19] yay, back to "normally screwed" instead of termially screwed [09:21] fwereade: By which I mean I don't think you mentioned that (I'll check now). I can change it though. [09:21] babbageclunk, sorry :( [09:23] katco: are you working on bug 1614559 ? [09:23] Bug #1614559: Juju rejects lxd 2.1