[00:08] anyone know what "juju.container interface.go:55 unused config option: "use-clone" -> "false"" is referring to? [00:12] stokachu, I think thumper added a feature for trusty users to make lxc fast using the lxc-clone feature [00:12] sinzui: ah this error shows up during kvm deploys [00:12] which makes sense if this is only for lxc [00:14] and only seems to show up when i set container: kvm in the environments.yaml for local [00:14] otherwise lxc is used for bootstrap while the others are kvm based [00:15] stokachu, its a warning isn't it? [00:15] sinzui: yea looks to be just a warning im running into issues where kvm instances aren't starting up though [00:16] http://paste.ubuntu.com/7122808/ [00:16] I see lots of warning because my configs are 1.16.6 and 1.17.6 [00:16] if i dont set container: kvm then i can deploy kvm's just fine, however, they dont honor the machine constraints [00:17] stokachu, I think the clone issue is just juju being verbose [00:18] ok cool, ill dig some more to see why i cant get these instances started [00:18] stokachu, the constraint issue may be bug 1294783 [00:18] <_mup_> Bug #1294783: deploy to kvm does not honor --constraints

[00:18] yea i filed that one lol [00:19] stokachu, sorry, my listing doesn't show reporters [00:19] was trying to work around it with using kvm as the bootstrap node [00:26] stokachu: the fact that it is showing up is a bug [00:26] stokachu: it shouldn't be [00:27] * thumper thinks... [00:27] yeah [00:27] it should omit it if it isn't there [00:28] yea looks like it did omit it as i got the kvm instances deployed, unfortunately, i coudn't get it to honor the constraints still [00:28] stokachu: what are you trying to do? [00:28] with the local provider, the host is the bootstrap node [00:28] so im working on a cloud-installer project where the single installer bootstraps juju onto a kvm instance and deploys openstack charms on separate instances [00:29] ah ok [00:29] so with that said im trying to get the kvm instances deployed with a --constraints mem=1G [00:30] ive tried juju set-constraints mem=6G and used juju deploy --to kvm:0 --constraints mem=1G [00:30] thinking i had to set the machine constraints to something that would allow 1G instances [00:30] umm... [00:31] only thing i haven't tried is juju add-machine --constraints mem=1G [00:31] you can't deploy onto machine 0 with the local provider [00:31] or at least you shouldn't be able to... [00:31] the containers are what im deploying to [00:31] under machine 0 [00:31] right, nope, that's not supported [00:32] if you are trying to do crazy stuff like that, the manual provider is the recommended way [00:32] anyone got a clue how to propose a merge from a remote dev box? [00:32] http://paste.ubuntu.com/7122846/ - thats not supported? [00:32] machine 0 is the host machine which connects to libvirt to create the containrrs [00:33] stokachu: the fact that it works is mildly surprising to me [00:33] it actually works better than lxc lol [00:33] but it isn't supported... [00:33] as in, I've not made sure it works [00:33] pardon my frustration, i've been sitting on this commit for like an hour while I eat dinner, hoping to get it at least proposed by the end of the night [00:34] so both lxc/kvm are not supported as containers to be deployed to on machine 0? [00:34] no [00:34] I guess it works [00:34] but it isn't supported [00:34] the networking isn't guaranteed to work for a start [00:34] if it does, it's a fluke [00:35] stokachu: the local provider works by creating containers "as machines" [00:35] so machine 1 on the local provider is normally lxc [00:35] stokachu: AFAIK, you are the first crazy person to try this [00:35] do i unlock an achievement award or anything? :D [00:36] sure... [00:36] * thumper hands stokachu an award [00:36] lol [00:36] however... [00:37] so with manual provider do i need to do anything special to deploy to kvm only? [00:37] you have successfully worked out how to have a mixed container local provider [00:37] with no extra work from me [00:37] hah yea i mixed kvm/lxc together on machine 0 [00:37] no... [00:37] do this [00:37] * thumper thinks... [00:38] actually, I should probably check this out locally first [00:38] the thing is, [00:38] the containers inside machine 0 [00:39] are just using the default dhcp [00:39] * thumper thinks harder [00:39] * thumper goes to read the source [00:39] yea whatever virbr0 is [00:39] i think [00:39] it creates a bunch of vnetX interfaces on the host machine too [00:41] right [00:41] so it is using the default bridge for kvm on the host [00:41] and lxc container would be using lxcbr0 [00:41] you could... make them talk [00:41] yea i didnt test if they could talk to each other [00:41] by changing 'lxc-bridge' -> virbr0 [00:42] ooo [00:42] bodie_, I am not current with what your stuck on, and I try to avoid lbox. Do you have a bzr issue? [00:42] in the config [00:42] im going to try that [00:42] then the lxc containers would use the same host bridge [00:42] stokachu: you are crazy btw [00:42] haha im not even sure how i got on this path [00:42] it just happened [00:43] sinzui, I'm working on a remote VPS because my local machine isn't passing tests due to the mongo stuff. [00:43] stokachu: and also, AWESOME [00:43] I have a bzr branch ready to lbox propose, but it wants me to use the web browser on the host [00:43] haha ty [00:43] waigani: I think I need to log into the bot and blow away the pkg dir [00:43] which is headless [00:44] waigani: it has to do with some things not being rebuilt that should be IMO [00:44] waigani: still referring to types that aren't there any more [00:44] waigani: not sure why go isn't rebuilding them properly [00:44] I tried using bzr, but I'm not sure what the workflow should be, and I'm getting stuck on bzr register-branch [00:44] thumper: right, I should probably learn how to do that sometime [00:45] bodie_: what are you doing? [00:45] I got it logged in to Launchpad.net on the remote via w3m, but it gets grumpy when I try to register-branch [00:45] bodie_, does bzr whoami agree with your email on lp [00:45] yeah [00:45] bodie_, does bzr lp-login prompt for you password [00:45] and doe you agree lp has your keys [00:46] bzr lp-login just shows my username [00:46] is so, I push branches to Lp before using lp everything, but lbox suck green donkey's **** [00:46] maybe the ssh key on my remote isn't my user's key [00:46] lol [00:46] stokachu: ok, and that warning you were getting for the kvm local provider, that is fixed in trunk [00:47] thumper: do I need to pass lxc Start a configFile/consoleFile or is it smart enough to read the ones passed in on creation? [00:47] `bzr push` works for me, though I have my bzr locations setup to push to the project, You can be explicit though.... [00:47] * thumper looks [00:47] bodie_, ... bzr push lp:~binary132/juju-core/my-branch [00:47] waigani: take what is now in the create container for the start bit, and move it into start container [00:48] waigani: then have create container call start container [00:48] thumper: sure [00:48] thanks sinzui. I owe you [00:48] now what? [00:49] thumper: sweet thanks [00:49] thumper: im actually testing that network-bridge option now [00:49] bodie_, I think lbox will honour where you put the branch so...can run [00:49] stokachu: so what does your provider config look like now? [00:50] bodie_, lbox propose -cr [00:50] thumper: http://paste.ubuntu.com/7122907/ [00:51] stokachu: FWIW, you don't need either of these two: "default-series: precise" or " authorized-keys-path: ~/.ssh/id_rsa.pub" [00:51] then i just do juju deploy --to [kvm|lxc]:0 [00:51] ah ok good to know [00:51] That will probably run some tests in a tainted environment, and if satisfied will crate the LP MP, followed by the RV...and then I fail half the time because it want me to login with an identity and password I try never to use [00:51] stokachu: for kvm, use --to kvm:0 [00:51] stokachu: for lxc, just do as normal [00:51] juju deploy foo [00:51] * thumper shakes his head [00:51] woohoo! https://code.launchpad.net/~binary132/juju-core/fix-bson-references/+merge/211847 [00:51] * thumper mutters ""crazy shit" [00:51] I did that via web portal [00:52] lol will be awesome if it works [00:52] bodie_: or as we like to refer to it as "launchpad" [00:52] ahhh SHIT! I didn't see there were conflicts..... [00:52] bodie_, :( conflicts. [00:52] wallyworld: got the bot ip address? [00:52] bodie_: always with conflicts [00:52] all the time [00:52] \o/ [00:52] 10.55.61.118 [00:53] sigh [00:53] bodie_, just push the updates, Lp will see the change and update the diff [00:54] :) looks like very few conflicts [00:54] ok [00:55] * thumper makes an alias gobot='ssh ubuntu@10.55.61.118' [00:55] wallyworld: how can I tell if the bot is currently trying to merge? [00:56] thumper: i just tail the log file in ~tarmac/logs [00:57] waigani: reapprove your branch now [00:57] sinzui -- so I need to merge trunk into my branch? [00:57] thumper: done [00:57] then I'll see the conflict and fix it [00:57] or do I need to branch trunk, merge my branch into that [00:58] bodie_, that right, merge trunk. the conflicts will be listed edit each file then use `bzr resolve` then `bzr commit` [00:59] ok [01:08] sinzui: https://bugs.launchpad.net/juju-core/+bug/1293330 [01:08] <_mup_> Bug #1293330: trusty charms are not deployable on ec2, causes provisioner to go into a restart loop [01:08] sinzui: you said ec2 trusty CI all green [01:09] It is, and you might see I tested it locally with the RC candidate. It passed [01:09] sinzui: can you try ap-southeast-2 [01:09] I will [01:09] sinzui: the regions shouldn't be different, but they are [01:12] thumper: landed! [01:19] thumper: looks like setting the network-bridge to virbr0 doesn't start lxc containers [01:19] stokachu: status? [01:19] kvm starts but lxc containers sit in a pending state [01:20] looking through the logs now to see whats going on [01:20] stokachu: is it downloading the lxc cloud image? [01:20] stokachu: are you on raring? [01:21] raring? no trusty [01:21] the host is saucy [01:21] it downloads the lxc-ubuntu-cloud image [01:21] run sudo lxc-ls --fancy [01:21] hah http://paste.ubuntu.com/7122992/ [01:21] i guess it does work [01:22] and juju ssh works [01:22] ohh and juju status updated its info from pending to started after i juju ssh'd [01:23] testing the trusted wordpress+mysql deployment :X [01:24] ok, think I cleared up the merge conflicts [01:24] ready for review! https://code.launchpad.net/~binary132/juju-core/fix-bson-references [01:24] really dumb fix [01:32] sweet [01:32] thumper: http://paste.ubuntu.com/7123027/ [01:32] works [01:33] stokachu: awesome [01:38] so what doesn't work is deploying to lxc on machine-0 [01:38] but everything else started up like a champ [01:38] yeah, don't do that [01:39] stokachu: because the lxc containers on machine 0 are using lxcbr0 [01:39] so on a different network [01:39] ah ok [01:42] thumper, I can reproduce the issue with ap-southeast-2. I attached the only log I could see to take https://bugs.launchpad.net/juju-core/+bug/1293330 [01:42] <_mup_> Bug #1293330: trusty charms are not deployable on ec2, causes provisioner to go into a restart loop [01:42] sinzui: ta [01:43] thumper: i guess my last question is should i keep my findings to myself? :) [01:44] stokachu: no [01:45] cool, i was thinking about a blog post but with a huge disclaimer lol [01:49] axw, regarding bug 1293198, I could try setting termination protection on the instance as juju is setting up. The call to destroy the machine will fail, so we can do an autopsy on the machine. [01:49] <_mup_> Bug #1293198: cannot bootstrap with win-client

[01:51] sinzui: one other thing you could do is run juju bootstrap with --debug [01:51] sinzui: then we can see what commands are being executed [01:52] axw, It didn't show me anything different before the error...it was identical to show-log from the call to apt-get update [01:52] I can get you the debug log in a few minutes though [01:53] thumper: ping [01:53] waigani: ya [01:53] pmed you [01:54] I'm probably off the bottom of your screen [01:54] I assume that by making a merge proposal it'll catch someone's attention soon enough? or do I need to ping people in here to get it reviewed? [01:55] sinzui: there should be a "Running script on..." line before any of the apt-get, etc. feedback [01:57] bodie_: mostly [01:57] yes [02:02] all righty [02:07] axw, I attached the debug log to the bug [02:07] sinzui: thanks [02:08] sinzui: mkdir -p '\var\lib\juju\agents\machine-0' [02:08] :( [02:08] should be easy to fix [02:08] ha ha [02:08] I'll get on that [02:23] axw: approved [02:25] thumper: thanks, just fixing ssh now... [02:29] sinzui: I just want to confirm something [02:29] sinzui: our trusty CI tests have trusty bootstrap nodes, yes? [02:30] thumper, status says so [02:30] sinzui: ok, cheers [02:30] just rebutting a bug [02:30] thumper, it download the precise? [02:30] I think so [02:30] sinzui: https://bugs.launchpad.net/juju-core/+bug/1293330/comments/2 [02:30] <_mup_> Bug #1293330: trusty charms are not deployable on ec2, causes provisioner to go into a restart loop [02:30] that is your status [02:31] showing bootstrap on trusty [02:31] which is good, because it matches the code [02:31] the checksum didn't match. I was going to download it and run sha256 [02:31] kk [02:31] wallyworld: where is the supported series stuff for providers? [02:32] um [02:32] there isn't really [02:32] you ask for an image for a series and it tells you if it has one [02:33] hmm... [02:33] eg you deploy cs:trusty/myql [02:33] it looks for a trusty image [02:34] if there's none there, then no deployed charm for you [02:34] wallyworld: I'm looking at the bootstrap issue [02:34] lets say I'm on a power machine [02:34] and I want to bootstrap to ec2 [02:34] ec2 doesn't have power [02:34] there, the series comes from denv config default-series [02:34] I don't think we should fail by default [02:35] power is the arch though [02:35] if they have explicitly specified an arch [02:35] then we can fail if it can't find one [02:35] if they didn't specify, then we should try with amd64 [02:35] that's what we do [02:35] hmm... no it isn't [02:35] because the tests fail [02:36] I think it is what we said we should do [02:36] but I don't think anyone has implemented it [02:36] so you saying it looks for an image with arch ppc64 [02:36] if none is specified [02:37] thumper: https://codereview.appspot.com/78070043 [02:37] looing [02:37] wallyworld: yep [02:37] wallyworld: and I'm saying that if we don't find ppc64, we should try amd64 [02:37] thumper: that's what constraints are for i guess [02:37] wallyworld, thumper . I just ran curl to get the tools again on the pending machine. My call got tools that passed the sah256sum [02:38] sinzui: that is just weird [02:38] CI was idle. It was publishing new tools... [02:38] i'm glad we put in the checksum then [02:38] but if a proxy is involved, maybe it delivered a version from a few hours ago [02:39] well I can deploy again and see if it works [02:39] turn it off and on again [02:40] thumper: the default fallback arch could be amd64, or it could be an env config just like "default-series" is [02:41] wallyworld: I think amd64 would be a good fallback [02:41] it has support everywhere [02:41] yes but i'm not sure explicit is always good [02:41] implicit imean [02:42] ymmv [02:42] I meant to say CI was idle, it was NOT publishing. I wouldn't have deployed using the release candidate if it was about to mutate [02:48] wallyworld, thumper, I deploy the charm again. It was successful. I think network/proxy is in play and my chosen test with a volatile version of juju is a factor [02:49] at least that explains it [02:54] thumper, I don't think bug 1293330 is critical, and I am not even sure it is high. [02:54] <_mup_> Bug #1293330: trusty charms are not deployable on ec2, causes provisioner to go into a restart loop [02:55] sinzui: me neither [02:55] sinzui: it is an ec2 issue? [02:55] or was it a tools sync issue? [02:56] I used streams [02:57] I suspect a proxy. I wouldn't work on this bug unless it was affect tools that had been release unchanged for a few days [03:05] wallyworld: https://codereview.appspot.com/78030044/ [03:05] wallyworld: it is small [03:05] and needed shortly by wai [03:05] waigani [03:05] ok [03:09] boo yeah [03:10] wallyworld: patching version.Current in two places fixes the bug [03:10] \o/ [03:10] wallyworld: it was just finding out where to put them :-) [03:10] i thought i got them all [03:10] clesrly not [03:10] confirmed fixed on power [03:11] thumper: reviewed with bikeshed [03:11] you know how much I love bikesheds [03:12] i think it is a good suggestion [03:12] much clearer intent [03:12] yeah, looks fine [03:12] to me [03:12] I'll paste you this other real simple branch as soon as lbox is done [03:12] https://code.launchpad.net/~thumper/juju-core/fix-ec2-test-isolation/+merge/211855 [03:12] or you can just look there [03:12] * wallyworld waits with baited breath [03:13] * thumper goes to make coffee [03:28] thumper: only if you have time. it's smaller than it looks because deletions. https://codereview.appspot.com/78030045 [03:28] otherwise i'll bother someone in europe to look [03:45] wallyworld: I have time [03:45] ok, ta [04:30] davecheney: why did you change the importance and milestone of https://bugs.launchpad.net/juju-core/+bug/1293330 after sinzui? [04:30] <_mup_> Bug #1293330: deploys may fail on ec2 when the juju tools are new.

[04:34] thumper: 'cos I think the bug is more serious [04:34] something is corrupting tools on download [04:34] davecheney: what makes you think that? [04:34] davecheney: no, nothing is corrupting it [04:34] the tools were changing [04:34] fine, change it back [04:35] not even going to ask why tools are being overwritten [04:35] I think it is part of the daily building of the latest code [04:35] the CI for tip [04:35] * davecheney puts fingers in ears [04:40] thumper: do you just want a comment for VType? the code has been there for a while [04:40] wallyworld: I just didn't know what it was [04:40] we were just not marshalling it [04:40] ok [04:40] no comment needed [04:40] ta [04:40] simplestreams can remain a black box :) [04:41] well, it's not simplestreams per se [04:41] it came from the old cloud init data format [04:41] before simplestreams [04:41] i'll make it more verbose [04:42] thumper: the pass by pointer question - not my code, but at a guess, we tend to pass structs by pointer in may places [04:43] why not there [04:43] sometimes we do, sometimes we don't [04:43] well, it is sorta my new code [04:43] if it is always passed [04:43] then that's fine [04:43] consider a lot of our XXXParams structs [04:44] they are always pass by value [04:44] not reference [04:44] is there a clear idiom [04:44] i prefer pass by pointer out of C++ habits [04:45] wallyworld: I prefer pass by reference [04:45] can't be nil [04:45] in C++ [04:46] true [05:07] * axw enjoys not having to think too much about object ownership === OutOfControl is now known as benonsoftware === vladk|offline is now known as vladk === vladk is now known as vladk|away === vladk|away is now known as vladk === thumper is now known as thumper-afk [06:15] wallyworld: I'm running into a problem where your new UploadTools logic is refusing to bootstrap the local provider. Have you run into this ? [06:16] jam1: have you pulled trunk? I fixed that first thing this morning [06:16] wallyworld: no I hadn't, that's why I was asking. Thanks [06:16] np. i refactored about 3 lots of the same logic together in one method and misinterpreted a flag === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk [08:06] good morning [08:11] morning vladk [08:16] dimitern, vladk: mornin' [08:16] hey rogpeppe :) [08:24] thumper-afk, when you can please check cadmin, I filled some leave for approval === vladk is now known as vladk|offline [08:29] morning dimitern, rogpeppe [08:29] jam1: hiya === vladk|offline is now known as vladk [08:30] jam1, dimitern, fwereade: currently looking for a review on this, if you have a little time: https://codereview.appspot.com/77600048 [08:30] rogpeppe, looking [08:30] dimitern: ta [08:32] rogpeppe: are you working on https://bugs.launchpad.net/juju-core/+bug/1271144? I'll take a look if you're not [08:32] <_mup_> Bug #1271144: br0 not brought up by cloud-init script with MAAS provider

[08:32] axw: wwitzel3 has been looking at that, i believe [08:32] okey dokey [08:33] axw: you might also want to take a look at https://codereview.appspot.com/77600048 BTW [08:33] rogpeppe: sure, will take a look [08:34] morning all [08:34] axw: last i heard, people were confused about the cause of the br0 issue. wwitzel3 checked it and it worked on his setup. but it failed for ahasenack. unless you have access to a MAAS, you'll find it difficult to test. [08:34] morning jam1 voidspace [08:34] voidspace: mornin' [08:34] morning voidspace [08:35]