[02:30] wallyworld: http://reviews.vapour.ws/r/5045/ [02:30] ok, ta [02:39] axw: while i'm looking, here's a small one http://reviews.vapour.ws/r/5046/ [02:39] wallyworld: okey dokey [02:55] axw: i wonder if migration should fail if the model credential does not exist in the target controller - should that check be done? i think so? [02:56] wallyworld: yeah, there's a TODO in NewModel to check that [02:56] ah right [02:56] wallyworld: intending to do in a follow up, can do in this branch if you prefer [02:56] follow up fine [02:56] it's all stuff immentently in progress [03:07] wallyworld: got a few minutes? [03:07] thumper: sure, just finishibg a review, give me 5 [03:07] wallyworld: ack, I'll jump in 1:1 and wait [03:14] axw: i left a few questions / suggestions [03:14] ta [03:15] thumper: found one typo. otherwise LGTM. [03:15] wallyworld: I was copying "CloudRegion() string" above in core/description. I can change both to ...Name() if you like, but IMO it's clear enough as it is [03:15] axw: ok [03:15] menn0: awesome [03:15] ta [03:36] wallyworld: please see replies [03:36] ok [03:39] axw: lgtm, we should think about the cloud config issue though [03:40] wallyworld: okey dokey. perhaps we could/should separate clouds.yaml management from the core representation of clouds/regions [03:41] wallyworld: maybe move clouds.yaml management into jujuclient? and then config-free version in cloud [03:41] just a thought... need to think through more [03:41] yep, i was thnking similar [03:53] bah humbug [03:54] wallyworld: where has the password gone from agent.Config ? [03:54] thumper: the api password? the one that used to be old-password? [03:55] there is no an old password, and no other passwords [03:55] it's in accounts.yaml [03:56] not on machine-0 [03:57] no, i think it was removed, but i'd need to check [03:58] i'm late for vet but i'm pretty sure it was removed from agent config because it's just not needed there [03:58] it is stored in the accounts yaml of the person who bootstrapped [03:58] yeah... [03:58] it is [03:58] and others get access via register [03:59] for the agent to connect over the api [03:59] screw users [03:59] I'm talking about agents [03:59] agents have the password elsewhere i thought [03:59] but can't recall offhand [03:59] hmm [03:59] but gotta run, bbiab [04:04] ah... [04:04] I should just be using APIInfo() [04:34] Bug #1525030 changed: 'ERROR while removing instance' when destroying lxd environment <2.0-count>

[04:34] Bug #1531719 changed: Runaway memory allocation in jujud unit agent <2.0-count> [04:43] Bug #1525030 opened: 'ERROR while removing instance' when destroying lxd environment <2.0-count>

[04:43] Bug #1531719 opened: Runaway memory allocation in jujud unit agent <2.0-count> [04:46] Bug #1525030 changed: 'ERROR while removing instance' when destroying lxd environment <2.0-count>

[04:46] Bug #1531719 changed: Runaway memory allocation in jujud unit agent <2.0-count> === frankban|afk is now known as frankban [06:37] axw: been looking at removing ControllerUUID() from environs.Config(). if it's to be done, it will need to involve constructing the Environ with the controller UUID, which means environs.New() and EnvironProvider.Open() will change [07:03] wallyworld: I think it's only needed by StartInstance and Destroy? [07:04] wallyworld: I was thinking we'd just add it to StartInstanceParams, and add a new DestroyAll(controllerUUID string), or something like that [07:08] axw: AllInstances needs it as well (for openstack at least) [07:08] and likely ControllerInstances() for others [07:10] wallyworld: ControllerInstances shouldn't need it, I'm pretty sure it's expected to be called on the controller Environ anyway [07:10] ControllerInstances() on openstack needs it [07:11] wallyworld: AllInstances shouldn't need the controller UUID either. I think we can change the openstack code [07:11] ok, i'll look to see if openstack is the only one where AllInstances needs it [07:43] dimitern: I tried http://reviews.vapour.ws/r/5040/ - LGTM but will test a little more with LXD this morning. If it's all OK I'll dump the distinction between multi and single NIC configs we talked about on Friday [07:44] frobware: great! thanks [07:45] frobware: I'm going to remove the legacy AC-FF code today as well [07:45] dimitern: need to sync with CI folks too as tests on their end should vanish [07:46] frobware: yeah, there's one affected test IIRC [07:53] axw: i think ec2 provider is broken for ControllerInstances() - it adds a filter based on model uuid not controller uuid. it may be that we only call it with the controller model environ so it works by fluke [07:53] wallyworld: pretty sure that's the only place we ever call it [07:53] wallyworld: I think we could reasonably restrict it to that [07:54] the caller can arrange to open the correct Environ, rather than requiring more of the provider [07:54] axw: yeah, we seem to call it to get an api connection from an env made from bootstrtap config [07:54] so i could change openstack to use ModelUUID and it would fix the current issue [07:55] but seems quite fragile [07:55] i could throw an error if cfg doesn't include a controller uuid attribute [07:56] that would stop any inadvertant usage slipping through [07:56] wallyworld: isn't the proposal for all configs to be that? :) [07:56] not model configs [07:56] model configs obtained from state will not include controller uuid [07:57] wallyworld: I thought the goal was to remove controller-uuid from environs.Config altogether [07:57] and i'd like to totally from controller uuid from from end processing too [07:57] yes, but we still need it at the front end at bootstrap [07:57] for now [07:57] it's a huge change [07:58] ok, I'm just saying if we intend to remove it eventually, it doesn't make sense to add more code dependent on its presence (or lack thereof) [07:58] but for now, if we just call ControllerInstances() to get api info (as a backup) then we need to assume controller uuid comes from coonfig [07:58] i could pass uuid to controller instances [07:59] that would work [07:59] wallyworld: sure, works for me [07:59] yay, more yak shaving [08:00] axw: and maas still appears to use the provider state file for ControllerInstances(), so we may be able to clean that up also [08:01] wallyworld: eep :/ [08:01] indeed [08:01] wallyworld: I thought thumper was adding the tags support. I guess he didn't get there yet [08:02] not enough friday afternoons [08:02] heh :) [08:02] but maas only *just* got tags support in 2.0 [08:02] maybe that bit was left out [08:02] ie tags are added but that code didn;t get fixed [08:02] yep I know, prereq for shortening the names though I thought [08:02] actually.. no, because we use agent-name [08:03] so just for getting rid of reliance on maas storage [08:03] well maas storage is still used for the provider state file [08:03] so maybe *now* we will be rid of it [08:04] yep, maas is all that uses it [08:04] so there'll be a bit deletion coming up [08:04] big [09:03] dimitern: dooferlad: babbageclunk: firefox being slow, omw [09:04] dimitern: frobware: dooferlad: babbageclunk: I'm in - I can hear but can't see anyone and no icons so I can't unmute yet... [09:04] frobware: standup? [09:05] omw [09:05] I should really get a headset with a mike - recommendations? [09:05] I keep getting kicked out as soon as it connects [09:06] frobware: try firefox? [09:07] start without me [09:08] babbageclunk: http://thewirecutter.com/reviews/best-usb-office-headset/ [09:11] dimitern: (et al) can't connect, which is weird since I just had a 1:1 with jam for an hour... [09:22] dimitern: keep on dropping again... :( [09:22] frobware: are you using chrome? [09:23] dimitern: yep, but tried FF. Just seems anything google-y. gmail and/or hangouts [09:25] frobware: I've seen this happen on Mondays usually :/ [09:26] dimitern: first call was fine; for standup call I had to do the auth dance, now I repeatedly get kicked out [09:27] frobware: I'd guess signing out completely and removing cookies might help (or try in an incognito window?) [09:27] voidspace: Thanks, those sound good (ha). Have you got one of them? [09:28] babbageclunk: no, I have some crappy old ones that need replacing [09:28] voidspace: aspirational then [09:28] babbageclunk: I'll buy the jabra I think [09:28] babbageclunk: I trust the wirecutter though [09:29] voidspace: I'm probably leaning towards the microsoft ones for better music sound. [09:30] babbageclunk: ah right - yeah, I don't use them for music [09:30] babbageclunk: I have 7:1 audio in my man cave [09:31] voidspace: ooh, nice. I assume it's all just ride of the valkyries then. [09:31] voidspace: And a fan to blow your hair back while you code. [09:31] babbageclunk: hehe, nice idea [09:53] Bug #1591939 opened: juju failed unmarshal the /server/{server_id} api response body [09:53] Bug #1591940 opened: juju failed unmarshal the /server/{server_id} api response body === admcleod_ is now known as admcleod [10:52] voidspace, dimitern, frobware: I'm trying to add a card to the Sapphire board for the application workload version work (well, the first part of it), but I get a permission error (maybe Leankit thinks I'm not on the team?). [10:53] babbageclunk: your should have access now [10:54] dimitern: Thanks! I'm looking at your change btw. [10:54] babbageclunk: thank you :) [10:56] dimitern: Hmm - I can't assign the card I just created to myself. [10:59] babbageclunk: try reloading lkk ? [10:59] dimitern: Yeah, that's it - thanks again! [11:00] :) [11:32] fwereade: hey, do you mind skipping our 1:1 ? [11:38] Bug #1401423 changed: networker should handle joyent-specific network config better

[11:38] Bug #1591962 opened: be able to set juju management network

[11:38] dimitern, np at all, I'd completely forgotten [11:52] dimitern: /etc/network/interfaces.d/eth0.cfg --<<< on MAAS images. I thought that had gone away. [11:59] Hello team can someone give #1591488 and/or #1591499 some love .. it is blocking preparing demos for next week events with partners .. (we are already late as partners sits on top of openstack) [11:59] Bug #1591488: Can not bootstrap on private openstack juju 1.25 or 2.0

[11:59] Bug #1591499: Bootstrap timeout and fail on private cloud

[12:06] frobware: is this on trusty? [12:06] thomnico: those look less like bugs and more like a cry for help [12:06] dimitern: ah yes [12:07] won't can not bootstrap for days qualify ?? [12:07] thomnico: he just doesn't have image metadata set properly [12:07] it does [12:07] frobware: is it missing when you disable cloud-init's networking? [12:07] hence the bug [12:07] thomnico: I can see from the log it's not, falls back to cloud-images.ubuntu.com [12:07] dimitern: don't know because we never do that for a MAAS image [12:08] yes this IS the buf [12:08] bug [12:08] thomnico: so, there's certainly some help needed [12:08] thomnico: see bug 1591225 etc [12:08] Bug #1591225: Generated image stream is not considered in bootstrap on private cloud [12:09] thomnico: for this one, it seems like image-metadata-url is just not set in environments.yaml or the streams have been incorrectly referenced [12:09] mgz, SO ?? [12:10] which is what cheryl suggested [12:10] I have been bootstraping juju on openstack for 3 years and helped customer doing it [12:10] frobware: you're testing my PR? does that eth0.cfg mess things up? [12:10] expect a recent change it is not a pebkac pb as far as I can tell [12:10] thomnico: we haven't released a new 1.25 recently [12:11] in 1591488 the cli tells juju to read the metadata and juju ignored it [12:11] thomnico: as far as I can see, image-metadata-url is not set [12:11] it must be. [12:12] that is new [12:12] and not documented as far as I can tell [12:13] it's what howto-privatecloud tells you to do [12:13] once set and checked I have : 1591499 [12:13] dimitern: no, was going back to http://reviews.vapour.ws/r/4969/ [12:13] dimitern: that it would be painless and quick (ha!) [12:14] frobware: ah :) [12:15] thomnico: does 192.168.16.5 mean the same thing from the machine being brought up in the private cloud? [12:15] if it can't route there it won't work [12:15] yes [12:15] dimitern: the problem with switching to ip route commands is we have no unit tests - we didn't before, but we were /only/ calling ifup/down [12:15] I use a jumpserver and they share the private network [12:16] thomnico: then you're probably into needing to set custom loglevel with trace for juju.environs.simplestreams then [12:16] I cheked it can be reached from the started VM [12:17] frobware: we can use the PatchExecutableAsEchoArgs (or the newer PatchExecHelper natefinch did recently) [12:17] dimitern: for? [12:17] can you copy paste the way to do that ?? [12:17] dimitern: oh, tests. [12:17] dimitern: sure [12:17] dimitern: however, the implementation is python. [12:19] frobware: I guess that will make it easier (at the slight expense of introducing non-go tests :) [12:19] dimitern: we still have the option of going back to ifup/down in light of some understanding around the boot failure [12:21] something like export JUJU_LOGGING_CONFIG="=DEBUG;juju.environs.simplestreams=TRACE" [12:21] frobware: I don't recall the ifup/down was tested? [12:21] dimitern: it wasn't. my point is that we were doing significantly less [12:21] thanks mgz will update the bug asap [12:22] dimitern: and was there / is there any value in validating that we call a command ifup/down? [12:22] frobware: I guess not much [12:22] dimitern: now we have lots of commands with varying args and we don't have much validation that we haven't changed something [12:23] frobware: but why go back to ifup/down when we know the boot slowdowns and issues ? [12:23] thomnico: remember --keep-broken stops juju taking the bootstrap machine down if it fails [12:23] great to know too :) [12:23] dimitern: separation of concerns. re my email a week ago: why don't we get the root cause fixed [12:24] ssh tail -f to local file was working too [12:24] FYI if it helps I can provide access to the evenrionment [12:25] frobware: ideally, we'll wait for the root cause to get fixed [12:25] frobware: however, judging by the comments on that ifupdown bug about restarting networking, it's highly unlikely [12:26] will need 1h or so to reproduce and collect traces .. cheers, [12:39] * dimitern whew... all tests pass again, after removing >7700 lines [13:03] hi there, anyone from juju resources?, have a short question [13:03] if anyway to set a default resource in metadata.yaml? [13:04] i'm looking to set a resource from local charmdir on deploy [13:07] my python workaround: mypath = resource_get(name) or os.path.join(charm_dir(), name) [13:24] mgz: ping [13:27] dimitern: yo [13:28] mgz: hey, I'm about to propose a PR which removes the legacy address allocation code [13:29] okay [13:29] mgz: once it lands, the CI job on AWS that uses the feature flag will no longer pass [13:29] Bug #1591499 opened: Bootstrap timeout and fail on private cloud

[13:29] I'll mkae it 1.25 only [13:30] mgz: ok, thanks! [13:30] so, for now aws containers are just not addressable right? [13:30] yeah [13:31] with the fan everywhere PoC though, we should get addressable containers by default [13:32] Bug #1591499 changed: Bootstrap timeout and fail on private cloud

[13:41] Bug #1591499 opened: Bootstrap timeout and fail on private cloud

[13:45] frobware, voidspace, babbageclunk: here it is - http://reviews.vapour.ws/r/5048/, please have a look [13:46] dimitern: do you think there's any value in having a branch to CI test this change? [13:47] frobware: we can do that, but I doubt it's necessary [13:48] dimitern: sure - just posing the question. And then I read the scrollback with mgz - so seems fine [13:51] frobware: yeah, I just disables/version-selected the ci jobs in advance [14:03] voidspace: if you can also have a look at http://reviews.vapour.ws/r/5040/ will be great ;) [14:33] fwereade: The service -> application change - do you know if there's still stuff being done on it? [14:35] fwereade: My understanding is it was just made to things that were externally visible (to make it vaguely manageable). If I'm making changes to internal things that are still using the old name, is it reasonable to also convert them to the new name at the same time? [14:54] dimitern, frobware: where are we with the lxd container networking issues? my lxc to lxd conversion branch (where we drop lxc support) can't land until we have parity with the old abilities to network lxc containers. [15:00] natefinch, we will not achieve complete parity give functional changes in netowrking of lxd [15:01] natefinch, there was one specific bug we needed to address for CI [15:01] natefinch, let me see if I can find it [15:02] babbageclunk, yes please, do convert as you can [15:02] fwereade: ok, thanks [15:03] alexisb: dimitern has proposed a change that just pulls out the old feature flag path completely [15:07] mgz, yep I see it [15:08] dimitern: ping [15:09] redir: standup time [15:14] hello again folks Bug #1591499 updated with trace [15:14] Bug #1591499: Bootstrap timeout and fail on private cloud

[15:21] katco, redir is sprinting this week I am pretty sure [15:21] alexisb: ah ok [15:25] voidspace: pong [15:26] natefinch: we have a few known lxd issues, most of which are in progress of getting fixed [15:28] natefinch: apart from those, I believe we have feature parity with lxc [15:29] dimitern:b awesome :) [15:29] dimitern: I'm (still) trying to understand link layer device parent references [15:30] dimitern: when generating increment ops we attempt to parse the name as a global key first - to see if it's a reference to another machine [15:30] dimitern: as far as I can tell, parentname is only *ever* set to a device name on the same machine [15:30] dimitern: am I missing something? [15:31] voidspace: ParentName can be a allowed to be a global key only in 1 case [15:31] dimitern: where is the code for that? [15:31] dimitern: (and what is that case) [15:31] if it's at all possible I'll have to allow for it I suppose [15:32] voidspace: when ParentName = "m#42#d#br-eth0" the child device will be e.g. m#42/lxd/0#d#eth1 [15:32] dimitern: right, but where in the code is that parent name generated [15:33] dimitern: in the machiner it looks like it's only ever set to device name [15:33] Bug #1592031 opened: update-clouds does not create public-clouds.yaml if public-clouds.syaml matches compiled-in values

[15:33] ParentDevice [15:33] voidspace: assuming machine 42 is the host machine of a container 42/lxd/0, and "eth1" is the container ethernet device connected to the "br-eth0" bridge device on the host machine [15:33] voidspace: yeah, the only place that uses the above scenario is SetContainerLinkLayerDevices, called in the provisioner [15:34] voidspace: ParentDevice returns the device itself, if it's set [15:34] dimitern: ah, the provisioner [15:34] dimitern: I did miss that - thanks [15:35] voidspace: yeah, but there are state tests as well [15:35] (apiserver/provisioner) [15:37] natefinch: btw my monstrous branch removing the legacy address allocation (http://reviews.vapour.ws/r/5048/) will conflict with your lxc removal branch, but hopefully not too badly, as it's mostly removals [15:41] dimitern: yeah, we'll see... I don't think it'll be a big deal... probably just resolving you changed it vs. I deleted it, and vice versa. [15:42] dimitern: between our two branches we deleted like 13,000 lines of code :D [15:42] natefinch: yeah, and it feels great! :D [15:43] cmars: is your npipe branch ready to go? [15:45] dimitern: ping, you about? Wanted to catch up regarding fe80:: addrs [15:45] frobware: yeah [15:46] frobware: it's not a big deal, I remembered reading about it and though it might be causing some of the issues perhaps [15:46] dimitern: but does it definitively happen? [15:47] cmars: I'm gonna answer that for you and say no it's not :) at the very least there's some commented out code in there... ping me when you think it's good to go, or if you need me to take it over and get it to a landable state. [15:47] alexisb: ^ [15:48] dimitern: http://pastebin.ubuntu.com/17293984/ [15:48] cmars: we want to try to get that landed today, so if me taking it over is what it'll take, that's fine. Just wanted to make sure you don't have local changes or anything. [15:49] frobware: I haven't t tested it specifically [15:49] dimitern: so that ^^ PB seems to propagate the fe80 addrs [15:50] frobware: yeah, looks ok [15:55] babbageclunk: thanks for sending that mail btw [15:56] dimitern: Cheers - wasn't sure what info to put in. It was ok? [16:04] dimitern: frobware dooferlad call? [16:04] rick_h_: omw [16:06] oops, omw [16:20] fwereade: ping [16:32] babbageclunk: you've covered all the important bits I think [16:32] dimitern: cool [16:33] frobware: so about http://reviews.vapour.ws/r/5040/ .. [16:33] frobware: should I leave it for tomorrow I guess? [16:33] dimitern: can I sleep on that one; I have a fix for my other review [16:34] dimitern: it may be that it's sensible to land your patch but only with a subset of my patch [16:35] dimitern: sound ok? [16:35] frobware: ok we can sync tomorrow then; and the other one ? http://reviews.vapour.ws/r/5048/ [16:36] dimitern: I would need to review but no real concerns there; we should update the release notes to say it has gone completely now [16:36] frobware: yeah, good point - I'll add a comment on the docs planing doc [16:40] ok, I should be going [17:47] hey has anyone hit this yet, or know a way around it -> https://bugs.launchpad.net/juju-core/+bug/1592101 [17:47] Bug #1592101: Error connecting with cached addresses [17:57] Bug #1592101 opened: Error connecting with cached addresses [18:04] bbl [18:09] Bug #1592101 changed: Error connecting with cached addresses [18:15] Bug #1592101 opened: Error connecting with cached addresses [19:34] Bug #1588574 changed: Session already closed in state/presence

[19:34] Bug #1590065 changed: container/lxd: One rename too far -> "application", "restart", "lxd-bridge"

[19:43] Bug #1588574 opened: Session already closed in state/presence

[19:43] Bug #1590065 opened: container/lxd: One rename too far -> "application", "restart", "lxd-bridge"

[19:46] Bug #1588574 changed: Session already closed in state/presence