| stokachu | anyone know what "juju.container interface.go:55 unused config option: "use-clone" -> "false"" is referring to? | 00:08 |
|---|---|---|
| sinzui | stokachu, I think thumper added a feature for trusty users to make lxc fast using the lxc-clone feature | 00:12 |
| stokachu | sinzui: ah this error shows up during kvm deploys | 00:12 |
| stokachu | which makes sense if this is only for lxc | 00:12 |
| stokachu | and only seems to show up when i set container: kvm in the environments.yaml for local | 00:14 |
| stokachu | otherwise lxc is used for bootstrap while the others are kvm based | 00:14 |
| sinzui | stokachu, its a warning isn't it? | 00:15 |
| stokachu | sinzui: yea looks to be just a warning im running into issues where kvm instances aren't starting up though | 00:15 |
| stokachu | http://paste.ubuntu.com/7122808/ | 00:16 |
| sinzui | I see lots of warning because my configs are 1.16.6 and 1.17.6 | 00:16 |
| stokachu | if i dont set container: kvm then i can deploy kvm's just fine, however, they dont honor the machine constraints | 00:16 |
| sinzui | stokachu, I think the clone issue is just juju being verbose | 00:17 |
| stokachu | ok cool, ill dig some more to see why i cant get these instances started | 00:18 |
| sinzui | stokachu, the constraint issue may be bug 1294783 | 00:18 |
| _mup_ | Bug #1294783: deploy to kvm does not honor --constraints <cloud-installer> <constraints> <kvm> <local-provider> <cloud-installer:New> <juju-core:Triaged> <https://launchpad.net/bugs/1294783> | 00:18 |
| stokachu | yea i filed that one lol | 00:18 |
| sinzui | stokachu, sorry, my listing doesn't show reporters | 00:19 |
| stokachu | was trying to work around it with using kvm as the bootstrap node | 00:19 |
| thumper | stokachu: the fact that it is showing up is a bug | 00:26 |
| thumper | stokachu: it shouldn't be | 00:26 |
| * thumper thinks... | 00:27 | |
| thumper | yeah | 00:27 |
| thumper | it should omit it if it isn't there | 00:27 |
| stokachu | 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 |
| thumper | stokachu: what are you trying to do? | 00:28 |
| thumper | with the local provider, the host is the bootstrap node | 00:28 |
| stokachu | 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:28 |
| stokachu | ah ok | 00:29 |
| stokachu | so with that said im trying to get the kvm instances deployed with a --constraints mem=1G | 00:29 |
| stokachu | ive tried juju set-constraints mem=6G and used juju deploy <charm> --to kvm:0 --constraints mem=1G | 00:30 |
| stokachu | thinking i had to set the machine constraints to something that would allow 1G instances | 00:30 |
| thumper | umm... | 00:30 |
| stokachu | only thing i haven't tried is juju add-machine --constraints mem=1G | 00:31 |
| thumper | you can't deploy onto machine 0 with the local provider | 00:31 |
| thumper | or at least you shouldn't be able to... | 00:31 |
| stokachu | the containers are what im deploying to | 00:31 |
| stokachu | under machine 0 | 00:31 |
| thumper | right, nope, that's not supported | 00:31 |
| thumper | if you are trying to do crazy stuff like that, the manual provider is the recommended way | 00:32 |
| bodie_ | anyone got a clue how to propose a merge from a remote dev box? | 00:32 |
| stokachu | http://paste.ubuntu.com/7122846/ - thats not supported? | 00:32 |
| stokachu | machine 0 is the host machine which connects to libvirt to create the containrrs | 00:32 |
| thumper | stokachu: the fact that it works is mildly surprising to me | 00:33 |
| stokachu | it actually works better than lxc lol | 00:33 |
| thumper | but it isn't supported... | 00:33 |
| thumper | as in, I've not made sure it works | 00:33 |
| bodie_ | 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:33 |
| stokachu | so both lxc/kvm are not supported as containers to be deployed to on machine 0? | 00:34 |
| thumper | no | 00:34 |
| thumper | I guess it works | 00:34 |
| thumper | but it isn't supported | 00:34 |
| thumper | the networking isn't guaranteed to work for a start | 00:34 |
| thumper | if it does, it's a fluke | 00:34 |
| thumper | stokachu: the local provider works by creating containers "as machines" | 00:35 |
| thumper | so machine 1 on the local provider is normally lxc | 00:35 |
| thumper | stokachu: AFAIK, you are the first crazy person to try this | 00:35 |
| stokachu | do i unlock an achievement award or anything? :D | 00:35 |
| thumper | sure... | 00:36 |
| * thumper hands stokachu an award | 00:36 | |
| stokachu | lol | 00:36 |
| thumper | however... | 00:36 |
| stokachu | so with manual provider do i need to do anything special to deploy to kvm only? | 00:37 |
| thumper | you have successfully worked out how to have a mixed container local provider | 00:37 |
| thumper | with no extra work from me | 00:37 |
| stokachu | hah yea i mixed kvm/lxc together on machine 0 | 00:37 |
| thumper | no... | 00:37 |
| thumper | do this | 00:37 |
| * thumper thinks... | 00:37 | |
| thumper | actually, I should probably check this out locally first | 00:38 |
| thumper | the thing is, | 00:38 |
| thumper | the containers inside machine 0 | 00:38 |
| thumper | are just using the default dhcp | 00:39 |
| * thumper thinks harder | 00:39 | |
| * thumper goes to read the source | 00:39 | |
| stokachu | yea whatever virbr0 is | 00:39 |
| stokachu | i think | 00:39 |
| stokachu | it creates a bunch of vnetX interfaces on the host machine too | 00:39 |
| thumper | right | 00:41 |
| thumper | so it is using the default bridge for kvm on the host | 00:41 |
| thumper | and lxc container would be using lxcbr0 | 00:41 |
| thumper | you could... make them talk | 00:41 |
| stokachu | yea i didnt test if they could talk to each other | 00:41 |
| thumper | by changing 'lxc-bridge' -> virbr0 | 00:41 |
| stokachu | ooo | 00:42 |
| sinzui | bodie_, I am not current with what your stuck on, and I try to avoid lbox. Do you have a bzr issue? | 00:42 |
| thumper | in the config | 00:42 |
| stokachu | im going to try that | 00:42 |
| thumper | then the lxc containers would use the same host bridge | 00:42 |
| thumper | stokachu: you are crazy btw | 00:42 |
| stokachu | haha im not even sure how i got on this path | 00:42 |
| stokachu | it just happened | 00:42 |
| bodie_ | sinzui, I'm working on a remote VPS because my local machine isn't passing tests due to the mongo stuff. | 00:43 |
| thumper | stokachu: and also, AWESOME | 00:43 |
| bodie_ | I have a bzr branch ready to lbox propose, but it wants me to use the web browser on the host | 00:43 |
| stokachu | haha ty | 00:43 |
| thumper | waigani: I think I need to log into the bot and blow away the pkg dir | 00:43 |
| bodie_ | which is headless | 00:43 |
| thumper | waigani: it has to do with some things not being rebuilt that should be IMO | 00:44 |
| thumper | waigani: still referring to types that aren't there any more | 00:44 |
| thumper | waigani: not sure why go isn't rebuilding them properly | 00:44 |
| bodie_ | 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 |
| waigani | thumper: right, I should probably learn how to do that sometime | 00:44 |
| thumper | bodie_: what are you doing? | 00:45 |
| bodie_ | 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 |
| sinzui | bodie_, does bzr whoami agree with your email on lp | 00:45 |
| bodie_ | yeah | 00:45 |
| sinzui | bodie_, does bzr lp-login prompt for you password | 00:45 |
| sinzui | and doe you agree lp has your keys | 00:45 |
| bodie_ | bzr lp-login just shows my username | 00:46 |
| sinzui | is so, I push branches to Lp before using lp everything, but lbox suck green donkey's **** | 00:46 |
| bodie_ | maybe the ssh key on my remote isn't my user's key | 00:46 |
| bodie_ | lol | 00:46 |
| thumper | stokachu: ok, and that warning you were getting for the kvm local provider, that is fixed in trunk | 00:46 |
| waigani | 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 |
| sinzui | `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 | |
| sinzui | bodie_, ... bzr push lp:~binary132/juju-core/my-branch | 00:47 |
| thumper | waigani: take what is now in the create container for the start bit, and move it into start container | 00:47 |
| thumper | waigani: then have create container call start container | 00:48 |
| waigani | thumper: sure | 00:48 |
| bodie_ | thanks sinzui. I owe you | 00:48 |
| bodie_ | now what? | 00:48 |
| stokachu | thumper: sweet thanks | 00:49 |
| stokachu | thumper: im actually testing that network-bridge option now | 00:49 |
| sinzui | bodie_, I think lbox will honour where you put the branch so...can run | 00:49 |
| thumper | stokachu: so what does your provider config look like now? | 00:49 |
| sinzui | bodie_, lbox propose -cr | 00:50 |
| stokachu | thumper: http://paste.ubuntu.com/7122907/ | 00:50 |
| thumper | stokachu: FWIW, you don't need either of these two: "default-series: precise" or " authorized-keys-path: ~/.ssh/id_rsa.pub" | 00:51 |
| stokachu | then i just do juju deploy <charm> --to [kvm|lxc]:0 | 00:51 |
| stokachu | ah ok good to know | 00:51 |
| sinzui | 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 |
| thumper | stokachu: for kvm, use --to kvm:0 | 00:51 |
| thumper | stokachu: for lxc, just do as normal | 00:51 |
| thumper | juju deploy foo | 00:51 |
| * thumper shakes his head | 00:51 | |
| bodie_ | woohoo! https://code.launchpad.net/~binary132/juju-core/fix-bson-references/+merge/211847 | 00:51 |
| * thumper mutters ""crazy shit" | 00:51 | |
| bodie_ | I did that via web portal | 00:51 |
| stokachu | lol will be awesome if it works | 00:52 |
| thumper | bodie_: or as we like to refer to it as "launchpad" | 00:52 |
| bodie_ | ahhh SHIT! I didn't see there were conflicts..... | 00:52 |
| sinzui | bodie_, :( conflicts. | 00:52 |
| thumper | wallyworld: got the bot ip address? | 00:52 |
| thumper | bodie_: always with conflicts | 00:52 |
| thumper | all the time | 00:52 |
| thumper | \o/ | 00:52 |
| wallyworld | 10.55.61.118 | 00:52 |
| bodie_ | sigh | 00:53 |
| sinzui | bodie_, just push the updates, Lp will see the change and update the diff | 00:53 |
| bodie_ | :) looks like very few conflicts | 00:54 |
| bodie_ | ok | 00:54 |
| * thumper makes an alias gobot='ssh ubuntu@10.55.61.118' | 00:55 | |
| thumper | wallyworld: how can I tell if the bot is currently trying to merge? | 00:55 |
| wallyworld | thumper: i just tail the log file in ~tarmac/logs | 00:56 |
| thumper | waigani: reapprove your branch now | 00:57 |
| bodie_ | sinzui -- so I need to merge trunk into my branch? | 00:57 |
| waigani | thumper: done | 00:57 |
| bodie_ | then I'll see the conflict and fix it | 00:57 |
| bodie_ | or do I need to branch trunk, merge my branch into that | 00:57 |
| sinzui | bodie_, that right, merge trunk. the conflicts will be listed edit each file then use `bzr resolve` then `bzr commit` | 00:58 |
| bodie_ | ok | 00:59 |
| thumper | 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 <juju-core:Triaged> <https://launchpad.net/bugs/1293330> | 01:08 |
| thumper | sinzui: you said ec2 trusty CI all green | 01:08 |
| sinzui | It is, and you might see I tested it locally with the RC candidate. It passed | 01:09 |
| thumper | sinzui: can you try ap-southeast-2 | 01:09 |
| sinzui | I will | 01:09 |
| thumper | sinzui: the regions shouldn't be different, but they are | 01:09 |
| waigani | thumper: landed! | 01:12 |
| stokachu | thumper: looks like setting the network-bridge to virbr0 doesn't start lxc containers | 01:19 |
| thumper | stokachu: status? | 01:19 |
| stokachu | kvm starts but lxc containers sit in a pending state | 01:19 |
| stokachu | looking through the logs now to see whats going on | 01:20 |
| thumper | stokachu: is it downloading the lxc cloud image? | 01:20 |
| thumper | stokachu: are you on raring? | 01:20 |
| thumper | raring? no trusty | 01:21 |
| stokachu | the host is saucy | 01:21 |
| stokachu | it downloads the lxc-ubuntu-cloud image | 01:21 |
| thumper | run sudo lxc-ls --fancy | 01:21 |
| stokachu | hah http://paste.ubuntu.com/7122992/ | 01:21 |
| stokachu | i guess it does work | 01:21 |
| stokachu | and juju ssh works | 01:22 |
| stokachu | ohh and juju status updated its info from pending to started after i juju ssh'd | 01:22 |
| stokachu | testing the trusted wordpress+mysql deployment :X | 01:23 |
| bodie_ | ok, think I cleared up the merge conflicts | 01:24 |
| bodie_ | ready for review! https://code.launchpad.net/~binary132/juju-core/fix-bson-references | 01:24 |
| bodie_ | really dumb fix | 01:24 |
| stokachu | sweet | 01:32 |
| stokachu | thumper: http://paste.ubuntu.com/7123027/ | 01:32 |
| stokachu | works | 01:32 |
| thumper | stokachu: awesome | 01:33 |
| stokachu | so what doesn't work is deploying to lxc on machine-0 | 01:38 |
| stokachu | but everything else started up like a champ | 01:38 |
| thumper | yeah, don't do that | 01:38 |
| thumper | stokachu: because the lxc containers on machine 0 are using lxcbr0 | 01:39 |
| thumper | so on a different network | 01:39 |
| stokachu | ah ok | 01:39 |
| sinzui | 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 <juju-core:Triaged> <https://launchpad.net/bugs/1293330> | 01:42 |
| thumper | sinzui: ta | 01:42 |
| stokachu | thumper: i guess my last question is should i keep my findings to myself? :) | 01:43 |
| thumper | stokachu: no | 01:44 |
| stokachu | cool, i was thinking about a blog post but with a huge disclaimer lol | 01:45 |
| sinzui | 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 <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1293198> | 01:49 |
| axw | sinzui: one other thing you could do is run juju bootstrap with --debug | 01:51 |
| axw | sinzui: then we can see what commands are being executed | 01:51 |
| sinzui | 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 |
| sinzui | I can get you the debug log in a few minutes though | 01:52 |
| waigani | thumper: ping | 01:53 |
| thumper | waigani: ya | 01:53 |
| waigani | pmed you | 01:53 |
| waigani | I'm probably off the bottom of your screen | 01:54 |
| bodie_ | 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:54 |
| axw | sinzui: there should be a "Running script on..." line before any of the apt-get, etc. feedback | 01:55 |
| thumper | bodie_: mostly | 01:57 |
| thumper | yes | 01:57 |
| bodie_ | all righty | 02:02 |
| sinzui | axw, I attached the debug log to the bug | 02:07 |
| axw | sinzui: thanks | 02:07 |
| axw | sinzui: mkdir -p '\var\lib\juju\agents\machine-0' | 02:08 |
| axw | :( | 02:08 |
| axw | should be easy to fix | 02:08 |
| sinzui | ha ha | 02:08 |
| axw | I'll get on that | 02:08 |
| thumper | axw: approved | 02:23 |
| axw | thumper: thanks, just fixing ssh now... | 02:25 |
| thumper | sinzui: I just want to confirm something | 02:29 |
| thumper | sinzui: our trusty CI tests have trusty bootstrap nodes, yes? | 02:29 |
| sinzui | thumper, status says so | 02:30 |
| thumper | sinzui: ok, cheers | 02:30 |
| thumper | just rebutting a bug | 02:30 |
| sinzui | thumper, it download the precise? | 02:30 |
| sinzui | I think so | 02:30 |
| thumper | 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 <juju-core:Triaged> <https://launchpad.net/bugs/1293330> | 02:30 |
| thumper | that is your status | 02:30 |
| thumper | showing bootstrap on trusty | 02:31 |
| thumper | which is good, because it matches the code | 02:31 |
| sinzui | the checksum didn't match. I was going to download it and run sha256 | 02:31 |
| thumper | kk | 02:31 |
| thumper | wallyworld: where is the supported series stuff for providers? | 02:31 |
| wallyworld | um | 02:32 |
| wallyworld | there isn't really | 02:32 |
| wallyworld | you ask for an image for a series and it tells you if it has one | 02:32 |
| thumper | hmm... | 02:33 |
| wallyworld | eg you deploy cs:trusty/myql | 02:33 |
| wallyworld | it looks for a trusty image | 02:33 |
| wallyworld | if there's none there, then no deployed charm for you | 02:34 |
| thumper | wallyworld: I'm looking at the bootstrap issue | 02:34 |
| thumper | lets say I'm on a power machine | 02:34 |
| thumper | and I want to bootstrap to ec2 | 02:34 |
| thumper | ec2 doesn't have power | 02:34 |
| wallyworld | there, the series comes from denv config default-series | 02:34 |
| thumper | I don't think we should fail by default | 02:34 |
| wallyworld | power is the arch though | 02:35 |
| thumper | if they have explicitly specified an arch | 02:35 |
| thumper | then we can fail if it can't find one | 02:35 |
| thumper | if they didn't specify, then we should try with amd64 | 02:35 |
| wallyworld | that's what we do | 02:35 |
| thumper | hmm... no it isn't | 02:35 |
| thumper | because the tests fail | 02:35 |
| thumper | I think it is what we said we should do | 02:36 |
| thumper | but I don't think anyone has implemented it | 02:36 |
| wallyworld | so you saying it looks for an image with arch ppc64 | 02:36 |
| wallyworld | if none is specified | 02:36 |
| axw | thumper: https://codereview.appspot.com/78070043 | 02:37 |
| thumper | looing | 02:37 |
| thumper | wallyworld: yep | 02:37 |
| thumper | wallyworld: and I'm saying that if we don't find ppc64, we should try amd64 | 02:37 |
| wallyworld | thumper: that's what constraints are for i guess | 02:37 |
| sinzui | wallyworld, thumper . I just ran curl to get the tools again on the pending machine. My call got tools that passed the sah256sum | 02:37 |
| thumper | sinzui: that is just weird | 02:38 |
| sinzui | CI was idle. It was publishing new tools... | 02:38 |
| wallyworld | i'm glad we put in the checksum then | 02:38 |
| sinzui | but if a proxy is involved, maybe it delivered a version from a few hours ago | 02:38 |
| sinzui | well I can deploy again and see if it works | 02:39 |
| wallyworld | turn it off and on again | 02:39 |
| wallyworld | thumper: the default fallback arch could be amd64, or it could be an env config just like "default-series" is | 02:40 |
| thumper | wallyworld: I think amd64 would be a good fallback | 02:41 |
| thumper | it has support everywhere | 02:41 |
| wallyworld | yes but i'm not sure explicit is always good | 02:41 |
| wallyworld | implicit imean | 02:41 |
| wallyworld | ymmv | 02:42 |
| sinzui | 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:42 |
| sinzui | 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:48 |
| wallyworld | at least that explains it | 02:49 |
| sinzui | 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 <juju-core:Triaged> <https://launchpad.net/bugs/1293330> | 02:54 |
| thumper | sinzui: me neither | 02:55 |
| thumper | sinzui: it is an ec2 issue? | 02:55 |
| thumper | or was it a tools sync issue? | 02:55 |
| sinzui | I used streams | 02:56 |
| sinzui | 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 | 02:57 |
| thumper | wallyworld: https://codereview.appspot.com/78030044/ | 03:05 |
| thumper | wallyworld: it is small | 03:05 |
| thumper | and needed shortly by wai | 03:05 |
| thumper | waigani | 03:05 |
| wallyworld | ok | 03:05 |
| thumper | boo yeah | 03:09 |
| thumper | wallyworld: patching version.Current in two places fixes the bug | 03:10 |
| wallyworld | \o/ | 03:10 |
| thumper | wallyworld: it was just finding out where to put them :-) | 03:10 |
| wallyworld | i thought i got them all | 03:10 |
| wallyworld | clesrly not | 03:10 |
| thumper | confirmed fixed on power | 03:10 |
| wallyworld | thumper: reviewed with bikeshed | 03:11 |
| thumper | you know how much I love bikesheds | 03:11 |
| wallyworld | i think it is a good suggestion | 03:12 |
| wallyworld | much clearer intent | 03:12 |
| thumper | yeah, looks fine | 03:12 |
| wallyworld | to me | 03:12 |
| thumper | I'll paste you this other real simple branch as soon as lbox is done | 03:12 |
| thumper | https://code.launchpad.net/~thumper/juju-core/fix-ec2-test-isolation/+merge/211855 | 03:12 |
| thumper | or you can just look there | 03:12 |
| * wallyworld waits with baited breath | 03:12 | |
| * thumper goes to make coffee | 03:13 | |
| wallyworld | thumper: only if you have time. it's smaller than it looks because deletions. https://codereview.appspot.com/78030045 | 03:28 |
| wallyworld | otherwise i'll bother someone in europe to look | 03:28 |
| thumper | wallyworld: I have time | 03:45 |
| wallyworld | ok, ta | 03:45 |
| thumper | 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. <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1293330> | 04:30 |
| davecheney | thumper: 'cos I think the bug is more serious | 04:34 |
| davecheney | something is corrupting tools on download | 04:34 |
| thumper | davecheney: what makes you think that? | 04:34 |
| thumper | davecheney: no, nothing is corrupting it | 04:34 |
| thumper | the tools were changing | 04:34 |
| davecheney | fine, change it back | 04:34 |
| davecheney | not even going to ask why tools are being overwritten | 04:35 |
| thumper | I think it is part of the daily building of the latest code | 04:35 |
| thumper | the CI for tip | 04:35 |
| * davecheney puts fingers in ears | 04:35 | |
| wallyworld | thumper: do you just want a comment for VType? the code has been there for a while | 04:40 |
| thumper | wallyworld: I just didn't know what it was | 04:40 |
| wallyworld | we were just not marshalling it | 04:40 |
| thumper | ok | 04:40 |
| thumper | no comment needed | 04:40 |
| wallyworld | ta | 04:40 |
| thumper | simplestreams can remain a black box :) | 04:40 |
| wallyworld | well, it's not simplestreams per se | 04:41 |
| wallyworld | it came from the old cloud init data format | 04:41 |
| wallyworld | before simplestreams | 04:41 |
| wallyworld | i'll make it more verbose | 04:41 |
| wallyworld | thumper: the pass by pointer question - not my code, but at a guess, we tend to pass structs by pointer in may places | 04:42 |
| wallyworld | why not there | 04:43 |
| thumper | sometimes we do, sometimes we don't | 04:43 |
| wallyworld | well, it is sorta my new code | 04:43 |
| thumper | if it is always passed | 04:43 |
| thumper | then that's fine | 04:43 |
| thumper | consider a lot of our XXXParams structs | 04:43 |
| thumper | they are always pass by value | 04:44 |
| thumper | not reference | 04:44 |
| wallyworld | is there a clear idiom | 04:44 |
| wallyworld | i prefer pass by pointer out of C++ habits | 04:44 |
| thumper | wallyworld: I prefer pass by reference | 04:45 |
| thumper | can't be nil | 04:45 |
| thumper | in C++ | 04:45 |
| wallyworld | true | 04:46 |
| * axw enjoys not having to think too much about object ownership | 05:07 | |
| === 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 | ||
| jam1 | 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:15 |
| wallyworld | jam1: have you pulled trunk? I fixed that first thing this morning | 06:16 |
| jam1 | wallyworld: no I hadn't, that's why I was asking. Thanks | 06:16 |
| wallyworld | np. i refactored about 3 lots of the same logic together in one method and misinterpreted a flag | 06:16 |
| === 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 | ||
| vladk | good morning | 08:06 |
| dimitern | morning vladk | 08:11 |
| rogpeppe | dimitern, vladk: mornin' | 08:16 |
| dimitern | hey rogpeppe :) | 08:16 |
| dimitern | thumper-afk, when you can please check cadmin, I filled some leave for approval | 08:24 |
| === vladk is now known as vladk|offline | ||
| jam1 | morning dimitern, rogpeppe | 08:29 |
| rogpeppe | jam1: hiya | 08:29 |
| === vladk|offline is now known as vladk | ||
| rogpeppe | jam1, dimitern, fwereade: currently looking for a review on this, if you have a little time: https://codereview.appspot.com/77600048 | 08:30 |
| dimitern | rogpeppe, looking | 08:30 |
| rogpeppe | dimitern: ta | 08:30 |
| axw | 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 <cloud-installer> <landscape> <local-provider> <lxc> <maas> <regression> <juju-core:Triaged by rogpeppe> <juju-core (Ubuntu):Triaged> <juju-core (Ubuntu Trusty):Triaged> <https://launchpad.net/bugs/1271144> | 08:32 |
| rogpeppe | axw: wwitzel3 has been looking at that, i believe | 08:32 |
| axw | okey dokey | 08:32 |
| rogpeppe | axw: you might also want to take a look at https://codereview.appspot.com/77600048 BTW | 08:33 |
| axw | rogpeppe: sure, will take a look | 08:33 |
| voidspace | morning all | 08:34 |
| rogpeppe | 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 |
| vladk | morning jam1 voidspace | 08:34 |
| rogpeppe | voidspace: mornin' | 08:34 |
| axw | morning voidspace | 08:34 |
| voidspace | vladk: axw: rogpeppe: morning | 08:35 |
| axw | rogpeppe: yeah, I don't at the moment | 08:35 |
| sparkiegeek | rogpeppe: axw: I can help with debugging that if you need it | 08:35 |
| axw | rogpeppe: the specific problem I was going to look at was bridge-utils not installing | 08:35 |
| rogpeppe | axw: yeah | 08:35 |
| rogpeppe | axw: that's the issue that was being looked at | 08:35 |
| sparkiegeek | axw: I can reproduce it every time :) | 08:35 |
| axw | sparkiegeek: thanks, I'll make sure I'm not duplicating effort first :) | 08:36 |
| axw | that helps | 08:36 |
| axw | rogpeppe: ok | 08:36 |
| rogpeppe | axw: do we set AptUpdate in the cloud-init we produce at bootstrap time? | 08:36 |
| axw | rogpeppe: no, it's done in the synch phase | 08:37 |
| rogpeppe | axw: ah, that may well be the problem | 08:37 |
| axw | rogpeppe: the simplest change would be to do it in both | 08:37 |
| rogpeppe | axw: yeah | 08:37 |
| axw | rogpeppe: I was going to modify the MAAS provider code to add it in specifically for MAAS though | 08:37 |
| axw | anyway, will wait to see if wwitzel3 has it under control | 08:38 |
| rogpeppe | axw: ok, why don't you do that? | 08:38 |
| rogpeppe | axw: given that we've got sparkiegeek around and eager to test for us :-) | 08:38 |
| axw | rogpeppe: why don't I do what? | 08:38 |
| sparkiegeek | axw: I tried compiling 1.17.5 but I got a failure with gwacl, if you give me a binary I can run with it | 08:38 |
| axw | sparkiegeek: okay cool, I'll try and knock one up | 08:38 |
| rogpeppe | axw: add AptUpdate to the cloud-init for maas | 08:38 |
| axw | sparkiegeek: got somewhere I can dump the binary? | 08:38 |
| jam1 | rogpeppe: hopefully one final review of https://codereview.appspot.com/76120044/ ? | 08:48 |
| rogpeppe | jam1: already done | 08:49 |
| jam1 | sparkiegeek: you should be able to cd $GOPATH/src/launchpad.net/gwacl; bzr update -r 231 | 08:50 |
| jam1 | we are using a slightly older version from tip because there are changes in progress | 08:50 |
| jam1 | (or bzr pull . -r 231 --overwrite, if update doesn't work) | 08:50 |
| jam1 | anyone have any ideas on: "... cannot use 37017 as state port, already in use" | 08:52 |
| jam1 | I'm trying to bootstrap the local provider | 08:52 |
| jam1 | and everything has been destroyed | 08:52 |
| jam1 | there is no local.jenv, and no jujud processes are running. | 08:52 |
| jam1 | now, I *can* telnet localhost 37017 | 08:53 |
| jam1 | but I don't think anything is actually running there | 08:53 |
| jam1 | ahh... hmmm. mongod is still running | 08:54 |
| jam1 | and destroy-environment --force isn't killing it | 08:54 |
| dimitern | rogpeppe, reviewed | 08:55 |
| rogpeppe | dimitern: ta! | 08:55 |
| dimitern | mgz, how's it going with https://codereview.appspot.com/77270046/ ? | 08:57 |
| sparkiegeek | jam1: so that moved me a little further along, but now I get http://paste.ubuntu.com/7124257/ | 08:58 |
| jam1 | sparkiegeek: well, the easiest thing is to use 'godeps', so "go get launchpad.net/godeps" and then "cd $GOPATH/src/launchpad.net/juju-core; godeps -u dependencies.tsv" | 08:59 |
| jam1 | which will set all your dependencies to the right version. | 08:59 |
| jam1 | rogpeppe: I think I'm comfortable enough doing "godeps -u" in the bot now, however we'll want to make sure it gets installed as part of the setup script. Do you have access to the Juju environment? | 09:00 |
| sparkiegeek | jam1: I was just following the README (hint hint, nudge, nudge) | 09:00 |
| rogpeppe | jam1: the gobot juju environment? | 09:00 |
| jam1 | rogpeppe: yeah | 09:00 |
| rogpeppe | jam1: funnily enough, i was at that very moment about to look at the gobot with a view to doing just that | 09:01 |
| rogpeppe | jam1: (because i want to update the code to use a more recent version of the ratelimit package) | 09:01 |
| rogpeppe | jam1: i do have access, yes | 09:01 |
| rogpeppe | jam1: (at least, i did last time i looked) | 09:02 |
| axw | rogpeppe: sparkiegeek has live tested my change and it works, so I've reassigned that bug to myself now - proposing a fix now | 09:12 |
| rogpeppe | mgz, jam: i'm thinking that after doing juju set on the gobot environment, we should probably do a "swift upload tarmac gobotnext.yaml" of the same data, right? | 09:12 |
| rogpeppe | axw: thanks! | 09:12 |
| jam1 | rogpeppe: yes | 09:13 |
| axw | fwereade: if you didn't see, I came up with a less stupid name for the API/param field: DistributionGroup | 09:17 |
| axw | well I think it's less stupid anyway | 09:17 |
| fwereade | axw, yeah, iliked that | 09:17 |
| axw | fwereade: also updated the code to do the right thing for env managers | 09:18 |
| fwereade | axw, I'm just pondering notfound vs unauthorized for unknown machines -- probably nbd but I need to think it through a bit | 09:18 |
| axw | fwereade: no worries, no rush. this stuff is hanging around till 1.19 anyway | 09:21 |
| axw | rogpeppe: do yo uhave a moment to look over https://codereview.appspot.com/77890045/ ? | 09:21 |
| rogpeppe | axw: looking | 09:22 |
| jam1 | mgz: where is https://bugs.launchpad.net/juju-core/+bug/1291165 at ? | 09:23 |
| _mup_ | Bug #1291165: empty .jenv file breaks destroy-environment and bootstrap <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1291165> | 09:23 |
| wwitzel3 | hello | 09:33 |
| === thumper-afk is now known as thumper | ||
| rogpeppe | axw: reviewed | 09:42 |
| axw | rogpeppe: thanks | 09:42 |
| axw | rogpeppe: you make a good point about just configuring the cloudinit.Config. ideally we would do both SetAptUpdate and AddPackage there, for MAAS only | 09:45 |
| axw | rogpeppe: I'd rather get this fixed though, so I'll add a tech-debt bug | 09:45 |
| rogpeppe | axw: sgtm | 09:45 |
| jam | morning wwitzel3, you should probably sync up with axw about the MaaS br0 bugs | 09:47 |
| jam | wwitzel3: axw has a patch, which should be landing now | 09:47 |
| axw | hey wwitzel3, just about to land https://codereview.appspot.com/77890045/ | 09:47 |
| axw | wwitzel3: fixes the apt-get bits, and uses ifdown/ifup instead of service networking restart | 09:47 |
| dimitern | jam, fwereade, I was thinking of creating a blueprint for MaaS VLAN support, so we can track the progress more easily | 09:48 |
| fwereade | dimitern, +100 | 09:48 |
| jam | dimitern: you can do so if you want, but *I* certainly find dragging cards on the Kanban board easier than editing the WIP of a blueprint | 09:48 |
| dimitern | jam, I'll take care of updating it regularly | 09:49 |
| wwitzel3 | axw: I was actually just reviewing that :) | 09:49 |
| axw | wwitzel3: ah, shall I hold off on approving then? | 09:49 |
| wwitzel3 | axw: I am pulling down that branch and will give it a go on my MaaS. I node that I setup with fastpath/curtin so I can verify the fix. | 09:50 |
| axw | wwitzel3: no idea what fastpath/curtin is, but sounds good - thanks | 09:51 |
| axw | wwitzel3: it has been live tested on Garage MAAS, fwiw | 09:51 |
| wwitzel3 | axw: well the OP of the bug was using the fastpath installer for maas, which turns out was the main difference in why my maas node had already run apt-get update and theirs had not. | 09:52 |
| sparkiegeek | wwitzel3: ahhh, that's what it was | 09:52 |
| axw | wwitzel3: ah, I see. thanks, would be good to know it still works in that mode then | 09:52 |
| sparkiegeek | axw: FWIW, it wasn't Garage MAAS, but A.N.Other MAAS | 09:53 |
| axw | sparkiegeek: oops, thanks for correcting me :) | 09:53 |
| perrito666 | good morning | 09:53 |
| wwitzel3 | sparkiegeek: yep, that was what we narrowed it down to | 09:53 |
| wwitzel3 | morning perrito666 | 09:53 |
| sparkiegeek | axw: fastpath (AKA Curtin) is download an image and dd it on to the disk, non fast path is regular debootstrap | 09:53 |
| axw | sounds nifty, I'll have to take a look | 09:54 |
| sparkiegeek | (i'm being a bit loose on the exact behaviour, but it's broadly like that) | 09:54 |
| rogpeppe | mgz, jam: where's a good place to install godeps on the 'bot so that it's accessible from tarmac verify scripts? | 09:58 |
| jam | rogpeppe: ~/.local/bin IIRC | 09:58 |
| jam | rogpeppe: we have some other stuff in there already, so it is in the $PATH for cron | 09:59 |
| rogpeppe | jam: ah, great, that's just what i needed to know. i was trying to think of a way of working out what $PATH was in that context | 09:59 |
| jam | rogpeppe: crontab -l | 09:59 |
| jam | rogpeppe, wwitzel3, dimitern, waigani: standup time | 10:00 |
| rogpeppe | vladk: ^ | 10:02 |
| rogpeppe | https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.sbtpoheo4q7i7atbvk9gtnb3cc | 10:02 |
| wwitzel3 | jam: hangouts is being a pest | 10:03 |
| wwitzel3 | attempting to get in there | 10:03 |
| jam | wwitzel3: you probably have to be on your canonical account | 10:03 |
| jam | we are over the 10 user threshold | 10:03 |
| jam | so it is a @canonical only hangout to get to 15 | 10:03 |
| axw | wwitzel3: thanks for the comments. I'll land what I've got and then look at refactoring. Probably trivial, but needs more testing | 10:06 |
| rogpeppe | voidspace: there's a meeting currently | 10:07 |
| rogpeppe | voidspace: see above | 10:07 |
| voidspace | ah | 10:07 |
| voidspace | thursday early meeting! | 10:08 |
| voidspace | rogpeppe: thanks | 10:08 |
| rogpeppe | voidspace: yeah | 10:08 |
| rogpeppe | voidspace: you will *just* fit in if you arrive now | 10:08 |
| axw | alexisb: if you're awake ^^ | 10:08 |
| voidspace | rogpeppe: too late I think | 10:09 |
| voidspace | "you aren't allowed to join this call" | 10:09 |
| voidspace | maybe the wrong identity, will try again | 10:09 |
| jam | voidspace: you have to join as your @canonical | 10:09 |
| jam | voidspace: easiest IME is to use the calendar event | 10:09 |
| jam | since it should be on the right calendar for you | 10:09 |
| rogpeppe | voidspace: add "?authuser=1" to the url | 10:09 |
| voidspace | jam: yea, that's what I did - thanks | 10:09 |
| voidspace | in | 10:09 |
| dimitern | vladk, found a nice tiny bug 1227074 we can quickly pair on later, if you want | 10:45 |
| _mup_ | Bug #1227074: runtime panic when running any juju command in a deleted directory <juju-core:Triaged> <https://launchpad.net/bugs/1227074> | 10:45 |
| perrito666 | dimitern: nothing that has panic on the title can be nice and tiny :p | 10:46 |
| vladk | dimitern: fine, but probably tomorrow, I am going on meeting with Mike Baker today | 10:47 |
| dimitern | vladk, sure, np | 10:47 |
| dimitern | perrito666, it's a silly panic anyway :) | 10:47 |
| vladk | dimitern: do we need that juju works from deleted directory or just change a panic to error? | 10:52 |
| dimitern | vladk, the latter | 10:52 |
| perrito666 | to test things with ec2, do we have an amazon account purposed for testing or should I use my own? | 10:55 |
| jam | dimitern: is there anything in juju that actually cares about $CWD? | 10:56 |
| jam | I don't really care if we fail, but it seems very spurious | 10:56 |
| natefinch | perrito666: use your own and expense it | 10:56 |
| dimitern | jam, apparently we just panic in that case | 10:56 |
| jam | (I know metadata generate-image cares, but aside from that) | 10:56 |
| perrito666 | natefinch: ack | 10:56 |
| jam | perrito666: I can give you creds for the shared account | 10:56 |
| wallyworld | mramm: bug 1248332 | 10:57 |
| jam | you're allowed to use your own and expense | 10:57 |
| _mup_ | Bug #1248332: user doc for simplestreams metadata and private clouds <docs> <juju-core docs:Triaged by evilnick> <https://launchpad.net/bugs/1248332> | 10:57 |
| jam | but I can give you creds as well | 10:57 |
| perrito666 | jam: as you prefer, both are the same to me, I guess Ill go with mine, since I only set it up for this and it is already set in juju | 10:58 |
| dimitern | jam, it seems the issue is cmd.DefaultContext includes the dir and that's why it reads os.Getwd() and panics | 10:58 |
| jam | perrito666: sure, you'll just have to go through the expensing it at the end of every month (which is a bit of a pain) | 10:58 |
| * perrito666 thinks that if he yawns a little bit more he will eat his coffee cup | 10:58 | |
| perrito666 | jam: I guess it is analog to the pain I had loading my national holidays :p | 10:59 |
| jam | perrito666: but you get to do it every month, and have to copy your receipts to expenses@canonical.com | 10:59 |
| natefinch | perrito666: I highly suggest setting up an alert for if your monthly bill goes over a certain amount (like $100). | 11:00 |
| natefinch | perrito666: (I had a $1000 bill a couple months ago due to forgetting about machines) | 11:00 |
| natefinch | 0. | 11:00 |
| natefinch | 2 | 11:00 |
| perrito666 | natefinch: dont worry, .ar govt takes care of making a big fuzz every time I spend US dollars | 11:00 |
| natefinch | perrito666: heh | 11:01 |
| wallyworld | fwereade: i can land this for 1.17.6 if you +1 it https://codereview.appspot.com/78030045/ | 11:01 |
| dimitern | wwitzel3, i might be able to help you with bug 1294776 if you get stuck btw | 11:03 |
| _mup_ | Bug #1294776: No debug-log with MAAS, 14.04 and juju-core 1.17.5 <logging> <regression> <juju-core:Triaged by wwitzel3> <https://launchpad.net/bugs/1294776> | 11:03 |
| wwitzel3 | dimitern: I have to get it setup a bit first, as my local maas is running precise | 11:04 |
| wwitzel3 | dimitern: but that shouldn't take took long | 11:05 |
| dimitern | wwitzel3, np | 11:05 |
| rogpeppe | wallyworld: so does something like this look plausible? http://paste.ubuntu.com/7124711/ | 11:07 |
| wallyworld | looking | 11:07 |
| wallyworld | rogpeppe: almost. the tools metadata is generated off tarballs, not just jujud. so we need to add a tar step | 11:08 |
| wallyworld | i'd have to look at the juju build tools code to see exatly what goes into a tarball | 11:09 |
| wallyworld | i think we could extend the generate-tools to doa build step | 11:09 |
| fwereade | wallyworld, +1, so long as it's explicit | 11:10 |
| wallyworld | yep | 11:10 |
| fwereade | wallyworld, it's the inscrutable magic in upload-tools that, uh, screws us | 11:10 |
| wallyworld | yeah | 11:10 |
| fwereade | wallyworld, https://codereview.appspot.com/78030045/ reviewed, no real blockers but I'd like a chat, brb for that | 11:11 |
| wallyworld | sure | 11:11 |
| rogpeppe | wallyworld: right, so that's the kind of thing i'm thinking of that we should really make trivial to do, and it doesn't appear to be currently | 11:11 |
| wallyworld | there would be release scripts for it too | 11:11 |
| wallyworld | since that's what the guys use for CI | 11:12 |
| wallyworld | so we could look at packaging those | 11:12 |
| wallyworld | so far there's been no need to do it externally (apart from release) because upload tools does it | 11:12 |
| wallyworld | but if we get rid of upload tools, i agree 100% we need to add tooling support | 11:13 |
| rogpeppe | wallyworld: it would actually be useful even without --upload-tools | 11:14 |
| rogpeppe | wallyworld: i mean, even *with* --upload-tools | 11:14 |
| rogpeppe | :-) | 11:14 |
| dimitern | rogpeppe, fwereade, mgz https://codereview.appspot.com/76910044 - Client.ServiceDeployWithNetworks API | 11:14 |
| wallyworld | sure :-) | 11:14 |
| wallyworld | rogpeppe: the release scripts are hosted on lp, i can't recall the branch name right now | 11:15 |
| wallyworld | fwereade: if you wanted a quick hangout to clarify the branch, i can do that. ping me when you are redy | 11:17 |
| fwereade | wallyworld, I'm back in the meeting hangout | 11:18 |
| fwereade | ah no | 11:18 |
| fwereade | rog/michael are there, let's start a new one | 11:18 |
| wallyworld | ok | 11:18 |
| fwereade | wallyworld, https://plus.google.com/hangouts/_/76cpi6pcd36amc6k6f520f6lq8?hl=en | 11:18 |
| === vladk is now known as vladk|away | ||
| === vladk|away is now known as vladk | ||
| === vladk is now known as vlad|lunch | ||
| rogpeppe | mgz: does this look reasonable as a gobot config setting? http://paste.ubuntu.com/7124775/ | 11:31 |
| rogpeppe | mgz: i've | 11:34 |
| rogpeppe | mgz: here are the diffs: http://paste.ubuntu.com/7124790/ | 11:34 |
| rogpeppe | jam: ^ | 11:34 |
| mgz | havin' a look | 11:34 |
| mgz | so, apart from being in the wrong format for juju set, amd I don't understand the diff at all | 11:36 |
| mgz | I'm oretty terriffied of go get as a tarmac test step | 11:36 |
| rogpeppe | mgz: oh shit, it contains private keys | 11:37 |
| rogpeppe | mgz: go get doesn't get anything if it's not already there | 11:37 |
| mgz | yeah, that sound have been paste.canonical.com :) | 11:37 |
| rogpeppe | s/not // | 11:37 |
| rogpeppe | mgz: do we need to change those keys now | 11:37 |
| rogpeppe | ? | 11:37 |
| mgz | doesn't matter too much as we don't give the bot a public ip, so only people in canonical could screw us anyway | 11:37 |
| mgz | rogpeppe: nah, just get IS to take the paste down | 11:38 |
| mgz | oh, well, the launchpad private key is bad | 11:38 |
| mgz | that's free access to our trunk | 11:38 |
| mgz | hey everyone, come modify juju-core | 11:39 |
| === vlad|lunch is now known as vladk|away | ||
| jam | rogpeppe: I would *not* do go get as a test step | 11:39 |
| jam | that, and it looks like you're wrapping the commands? | 11:39 |
| jam | not sure why it looks that way | 11:39 |
| rogpeppe | jam: i can't see how to get around it - how else do we add a new dependency without manually editing the configuration script? | 11:40 |
| rogpeppe | jam: and go get is a no-op unless we've added a new dependency | 11:40 |
| jam | rogpeppe: we have to do the work when updating a dep anyway | 11:40 |
| jam | since you aren't doing -u | 11:40 |
| fwereade | mgz, hey, btw, joyent-provider-storage still seems to be hanging around | 11:41 |
| fwereade | mgz, we fixed the deps, right? | 11:41 |
| rogpeppe | jam: when we update a dep, we can just do juju set tarmac bogus=foo | 11:41 |
| jam | rogpeppe: well, we could do that anyway then | 11:41 |
| rogpeppe | jam: to poke the bot into running the config-changed hook | 11:41 |
| rogpeppe | jam: that doesn't help when we add a new dependency | 11:42 |
| rogpeppe | jam: because the dependency won't be in trunk | 11:42 |
| rogpeppe | jam: so go get -u .../juju-core/... won't fetch it | 11:42 |
| jam | rogpeppe: I'm willing to have some potentially dangerous operations be manual, tbh | 11:42 |
| jam | if it isn't something that happens all the time | 11:42 |
| rogpeppe | jam: i'm not sure what you mean by "wrapping the commands" BTW. are you referring to the yaml quoting wrapping? | 11:42 |
| rogpeppe | jam: why is this potentially dangerous? | 11:43 |
| jam | rogpeppe: your diff has certain "verify_command" lines on 2 lines | 11:43 |
| rogpeppe | jam: yaml quoting concatenates lines that aren't separated by a blank line | 11:43 |
| jam | rogpeppe: it is downloading 3rd party code without a human actualyl running the command | 11:43 |
| rogpeppe | jam: so is the "go get -u .../juju-core/... | 11:44 |
| rogpeppe | " | 11:44 |
| jam | rogpeppe: we initi | 11:45 |
| jam | initiate it manually by changing config | 11:45 |
| jam | vs everytime the bot sees a branch to merge | 11:45 |
| rogpeppe | jam: maybe we should have a separate config setting holding additional branches to go-get | 11:46 |
| jam | rogpeppe: that sounds like a good way to trigger it. | 11:46 |
| rogpeppe | jam: in fact, that would be trivial to do, i think | 11:46 |
| rogpeppe | jam: i don't think it requires any changes to the charm | 11:47 |
| * perrito666 wishes he would stop writing git pull when he tries to bzr pull | 11:49 | |
| mgz | perrito666: `alias git="echo use bzr you fool"` | 11:51 |
| jam | mgz: that won't work for *too* much longer :) | 11:51 |
| perrito666 | mgz: that is actually an idea I am really considering | 11:51 |
| mgz | you just need a noreallygit alias too :) | 11:51 |
| jam | mgz: well "\git" is that in bash, IIRC | 11:52 |
| perrito666 | heh, I will only have this machine until friday so I could very well do that | 11:52 |
| rogpeppe | jam, mgz: ok, how about this? http://paste.ubuntu.com/7124845/ | 11:52 |
| jam | you can certainly do "\rm foo" to get around "alias rm=rm stuf" | 11:52 |
| * rogpeppe only just manages to avoid pasting private keys again :-) | 11:52 | |
| mgz | rogpeppe: where is that unzip mongodb-server coming from | 11:53 |
| rogpeppe | unalias -a is my friend | 11:53 |
| perrito666 | I could actually do a wrapper that checks in what kind of repo I am and do the proper thing without making me feel bad for misspelling bzr :p | 11:53 |
| mgz | rogpeppe: I nearly poked you :) | 11:53 |
| rogpeppe | mgz: that's already there | 11:53 |
| rogpeppe | mgz: it's actually the end of an apt-get install line | 11:54 |
| rogpeppe | mgz: those are two packages that it's apt-get installing | 11:54 |
| mgz | oh dear god the diff syntax | 11:54 |
| mgz | I see | 11:54 |
| mgz | thanks | 11:54 |
| rogpeppe | mgz: but yaml has wrapped the line, oh so helpfully | 11:54 |
| rogpeppe | dimitern: i've made (almost) all the changes pwd | 12:10 |
| rogpeppe | dimitern: ignore me for the moment | 12:10 |
| rogpeppe | dimitern: PTAL https://codereview.appspot.com/77600048 | 12:13 |
| rogpeppe | mgz: so does it look ok? | 12:13 |
| rogpeppe | mgz: if so, i'll try it out | 12:13 |
| fwereade | bodie_, ping | 12:14 |
| mgz | perrito666: it seems you have bzr whomai borked on your local machine | 12:14 |
| mgz | it's "Horacio n <horacio.duran@canonical.com>Dur" | 12:14 |
| perrito666 | mgz: ah, marvels of intermachine encoding | 12:14 |
| mgz | I guess macs suck with non-ascii? :P | 12:14 |
| fwereade | mgz, did I miss a response to the joyent-storage question? | 12:14 |
| perrito666 | mgz: that is actually ubuntu server | 12:14 |
| bodie_ | fwereade, what's up :) | 12:15 |
| perrito666 | which does indeed suck with a few things non ascii | 12:15 |
| mgz | fwereade: probaly not, it just needs landing | 12:15 |
| mgz | something's been borked whenever I've tried, but I could actually force it through | 12:15 |
| fwereade | bodie_, hey, i saw just looking at your MP -- would it be possible to get lbox set up so I can do shiny happy line-by-line comments on the review? | 12:15 |
| fwereade | bodie_, to be fair, I haven't seen anything that needs commenting yet | 12:16 |
| perrito666 | mgz: thanks for the heads up, Ill fix it | 12:16 |
| mgz | perrito666: r2437.3.3 is fine, and that's the one *I* committed on ubuntu server :) | 12:16 |
| fwereade | bodie_, but referencing particular bits of code inLP reviews is really tedious ;) | 12:16 |
| bodie_ | Understand, what's missing for me to be fully set up? | 12:17 |
| bodie_ | Rietveld? | 12:18 |
| perrito666 | mgz: again, my ubuntu server :p | 12:18 |
| rogpeppe | natefinch: ping | 12:20 |
| fwereade | bodie_, in one of the docs -- possibly CONTRIBUTING? it describes lbox setup | 12:20 |
| fwereade | bodie_, I'm pretty sure you just need to auth with google on the CLI to use it | 12:21 |
| natefinch | rogpeppe: sorta here | 12:21 |
| rogpeppe | natefinch: if you had a moment, i wondered if you could join this call for a few moments to discuss bootstrap-state | 12:22 |
| fwereade | bodie_, it also enforces description format and lets you auto-link bugs and stuff | 12:22 |
| rogpeppe | wwitzel3 too, presuming you're pairing with nate currently | 12:22 |
| bodie_ | fwereade, the problem is that I'm working on a headless remote host configured with 13.10 since my local workstation is on 14.04 and refuses to play nice | 12:22 |
| rogpeppe | https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.sbtpoheo4q7i7atbvk9gtnb3cc?authuser=1 | 12:22 |
| bodie_ | I tried using the happy MP technique in the doc and it asked me to open a web browser, which was impossible... | 12:23 |
| wwitzel3 | rogpeppe: I'm here | 12:23 |
| fwereade | bodie_, you don't need to do anything *right now*, I've just approved it for you | 12:23 |
| fwereade | bodie_, for which, tyvm | 12:23 |
| fwereade | bodie_, sorry brb | 12:23 |
| rogpeppe | wwitzel3: could you join us? | 12:23 |
| rogpeppe | dimitern: any chance of a LGTM on that branch you reviewed? | 12:25 |
| wwitzel3 | rogpeppe: keep getting not allowed to join | 12:25 |
| natefinch | rogpeppe: joining | 12:25 |
| rogpeppe | wwitzel3: try changing authuser=1 to authuser=0 | 12:25 |
| rogpeppe | wwitzel3: in the URL | 12:25 |
| jam | wwitzel3: probably need to be in your canonical account | 12:25 |
| wwitzel3 | yep on my canonical account | 12:26 |
| wwitzel3 | rogpeppe: can you send me an invite | 12:26 |
| jam | wwitzel3: the account is hard-coded in that URL (the first or second login with "authuser") | 12:26 |
| jam | I usually strip that off | 12:26 |
| perrito666 | mgz: apparently "I am in argentina but set this up as an english server" confused a little bit the settings and it let me without proper LC_ALL | 12:27 |
| wwitzel3 | jam: it tells me I am the first one there, then I join, and then I get the not allowed message, this is on my canonical account, tried authuser=0 and removing it al ltogether | 12:28 |
| jam | wwitzel3: I just invited your Canonical account | 12:29 |
| wwitzel3 | jam: thanks | 12:29 |
| jam | wwitzel3: well, the link worked for me, but meh :) | 12:29 |
| bodie_ | http://blog.labix.org/2011/11/17/launchpad-rietveld-happycodereviews | 12:31 |
| bodie_ | anyone know if there's a way to do this in headless mode? | 12:31 |
| bodie_ | I'm working on a remote while we get 14.04 mongo nonsense up to speed | 12:31 |
| bodie_ | speaking of which, here's today's 14.04 mongo nonsense if anyone has a few brain cells to spare: http://paste.ubuntu.com/7124946/ | 12:32 |
| dimitern | rogpeppe, i was mostly concerned with not using statetesting | 12:35 |
| dimitern | rogpeppe, LGTM | 12:36 |
| dimitern | rogpeppe, fwereade, I still need a review on https://codereview.appspot.com/76910044 please | 12:37 |
| fwereade | bodie_, is that consistent? we have intermittent "no reachable servers"es that nobody's managed to get to the bottom of | 12:37 |
| dimitern | mgz, ping | 12:38 |
| mgz | dimitern: hey | 12:38 |
| bodie_ | i'll double-check, but i'm pretty sure this is what I got last time | 12:38 |
| jam | fwereade: bodie_: that particular test can just be run again, we haven't managed to track down why it takes >45s to start up the server. | 12:38 |
| jam | it doesn't usually | 12:38 |
| dimitern | mgz, I was wondering about your serviceNetworks branch | 12:38 |
| rogpeppe | dimitern: thanks! | 12:38 |
| fwereade | jam, wrt dimitern's review, I feel like we *really* need API versioning :/ | 12:39 |
| dimitern | mgz, how far away are you from landing it? | 12:39 |
| mgz | dimitern: yeah, I need to add a test and land it, have just been poking jenv things | 12:39 |
| fwereade | dimitern, and I'm afraid I have to eat, cath's just back | 12:39 |
| mgz | if it's blocking your path I'll go ahead and do that | 12:39 |
| dimitern | fwereade, sure, when you can | 12:39 |
| dimitern | mgz, almost - i can land mine without yours and then do a follow-up | 12:39 |
| dimitern | to integrate | 12:40 |
| mgz | dimitern: I'll go ahead and finish it up | 12:40 |
| dimitern | mgz, cheers! | 12:40 |
| dimitern | perrito666, are you working on "CLI "juju deploy --network/--exclude-network"" card? | 12:40 |
| perrito666 | dimitern: I began last night but reached nothing in the time I had, I am now with the bug fwereade just threw at me, you can take it if you want (I just assigned to myself next available task, I have no particular interest in it" | 12:42 |
| perrito666 | ) | 12:42 |
| dimitern | perrito666, not to worry, just checking to update the blueprint | 12:42 |
| fwereade | mgz, can you handle the joyent call tonight? I need to stop a bit early | 12:49 |
| mgz | fwereade: sure | 12:49 |
| bodie_ | newest 14.04 mongo stuff (you were right jam, the timeouts went away on their own -- this is what I was seeing yesterday) | 12:55 |
| bodie_ | http://paste.ubuntu.com/7125084/ | 12:55 |
| === vladk|away is now known as vlad|lunch | ||
| === vlad|lunch is now known as vladk|away | ||
| === vladk|away is now known as vlad|lunch | ||
| === vlad|lunch is now known as vlad| | ||
| === vlad| is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| dimitern | rogpeppe, do you have time to look at https://codereview.appspot.com/76910044 ? | 13:07 |
| rogpeppe | dimitern: am currently pairing with voidspace; should be able to have a look later. | 13:08 |
| dimitern | rogpeppe, ok then | 13:08 |
| rogpeppe | dimitern: could we not just add IncludedNetworks and ExcludedNetworks to params.ServiceDeploy, and make sure that the behaviour when they're empty is the same as the current behaviour of Deploy? | 13:32 |
| rogpeppe | dimitern: i.e. keep the existing API call | 13:32 |
| dimitern | rogpeppe, except we can't verify if the apiserver actually did anything when we set these | 13:33 |
| dimitern | rogpeppe, (i.e. an old server will just ignore them) | 13:33 |
| dimitern | rogpeppe, hence the new API call - we can test whether it's supported | 13:34 |
| rogpeppe | dimitern: if we're talking to an old server, is giving an error actually better than doing something without networks? | 13:35 |
| rogpeppe | dimitern: (given that we can't specify networks on that server) | 13:35 |
| bodie_ | did anyone have any thoughts on that test report? | 13:35 |
| bodie_ | oh | 13:36 |
| bodie_ | it's the mapreduce issue with not having the js engine | 13:36 |
| dimitern | rogpeppe, yes, because we can detect and report it immediately, rather than hitting issues later | 13:36 |
| dimitern | rogpeppe, if the server does not support it, that's fine - we can't do it, but it's better to know early from UX perspective | 13:37 |
| bodie_ | should I open a bug report for the issue? | 13:38 |
| dimitern | bodie_, it seems you're using the juju-mongodb package? | 13:40 |
| dimitern | bodie_, it doesn't have the v8 js engine built-in, hence the error | 13:40 |
| bodie_ | right | 13:40 |
| bodie_ | so that's a bug, right? | 13:40 |
| dimitern | bodie_, please file one, yes | 13:41 |
| bodie_ | I know natefinch and a couple of others were discussing this yesterday | 13:41 |
| bodie_ | now, I'm not getting this error on my 13.10 instance | 13:42 |
| bodie_ | even though it is configured the same way (with juju-mongodb) | 13:42 |
| dimitern | that's because the package in saucy is probably different? | 13:43 |
| bodie_ | however, I think its version of juju-mongodb is different -- 2.4.6 | 13:43 |
| bodie_ | yeah | 13:43 |
| rogpeppe | dimitern: ok, i guess that's fair enough | 13:45 |
| rogpeppe | dimitern: i don't see why we don't make DeployWithNetworks backwardly compatible with Deploy though | 13:46 |
| dimitern | rogpeppe, what do you mean? | 13:47 |
| rogpeppe | dimitern: well, you currently require some networks to be set | 13:47 |
| rogpeppe | dimitern: i don't really see that's necessary | 13:47 |
| dimitern | rogpeppe, that's the only thing different from servicedeploy | 13:48 |
| dimitern | rogpeppe, why'd you call it otherwise? | 13:48 |
| rogpeppe | dimitern: if it wasn't for the backward compatibility issue, we'd just call it Deploy, right? | 13:48 |
| rogpeppe | dimitern: in some ways it would just be better to call this DeployV2 or something | 13:48 |
| rogpeppe | dimitern: from a client point of view, they could *always* call DeployWithNetworks rather than Deploy | 13:49 |
| natefinch | bodie_: the current position is that juju-mongodb is *only* for trusty, and older versions should use regular mongodb (with SSL) | 13:49 |
| dimitern | rogpeppe, yeah | 13:49 |
| rogpeppe | dimitern: (and that's true for our client code too) | 13:49 |
| dimitern | rogpeppe, and if we *had* api versioning it would've been even easier | 13:49 |
| natefinch | bodie_: sorry... you hit us just as this stuff was stabilizing (but before it was actually stable) | 13:50 |
| rogpeppe | dimitern: not sure about that - if we went william's direction, you'd need to copy the entire API code | 13:50 |
| bodie_ | all good, I got my remote working so I'm happy | 13:51 |
| bodie_ | natefinch, isn't the juju-mongodb on Saucy just a repackaging of the system default? | 13:52 |
| dimitern | rogpeppe, any api should have means of telling you "i support this" for a specific version | 13:52 |
| bodie_ | https://bugs.launchpad.net/juju-core/+bug/1295140 <--- filed bug | 13:52 |
| _mup_ | Bug #1295140: Trusty juju-mongodb map-reduce fails due to lacking js engine <js> <mongodb> <trusty> <juju-core:New> <https://launchpad.net/bugs/1295140> | 13:52 |
| natefinch | bodie_: I have no idea. Possibly. | 13:52 |
| dimitern | rogpeppe, and the ability to change the interface between versions | 13:52 |
| dimitern | esp. one we need to support for 5y | 13:52 |
| bodie_ | another question: let's say I want to run "real" mongo on my workstation (I'm working on another project that uses it, which might need the js engine.) Can I have both packages installed? | 13:53 |
| rogpeppe | dimitern: for this specific thing, i had in mind that we could ask the API what calls it supports, and potentially what the argument and return types look like | 13:53 |
| bodie_ | also, hullo | 13:53 |
| rogpeppe | dimitern: that would have made it easy to add arguments to the call and still preserve the ability to check that the API implements it correctly, without needing versioning | 13:53 |
| rogpeppe | dimitern: one other thing: you can embed params.ServiceDeploy into params.ServiceDeployWithNetworks | 13:54 |
| dimitern | rogpeppe, yeah, that will save us a lot of boilerplate in the long run | 13:54 |
| dimitern | rogpeppe, i did that initially, but didn't like it very much | 13:55 |
| natefinch | bodie_: no idea about having multiples. I just have one, which is real mongodb built with SSL. That's probably your best bet. | 13:55 |
| dimitern | rogpeppe, wasn't sure it'll serialize properly as well to be honest | 13:55 |
| rogpeppe | dimitern: it serialises correctly | 13:55 |
| rogpeppe | dimitern: here's another possibility: just add the parameters to Deploy | 13:55 |
| rogpeppe | dimitern: but also add DeployWithNetworks as an alias for Deploy | 13:56 |
| bodie_ | yeah, that would be nice to get working | 13:56 |
| bodie_ | but since make install-dependencies installs juju-mongodb, I feel like that should work before I go tweaking things to make it work | 13:56 |
| dimitern | rogpeppe, hmm.. that's a interesting possibility | 13:56 |
| bodie_ | I have my remote working, so I'm content until that gets cleared up | 13:56 |
| rogpeppe | dimitern: then clients that care can call DeployWithNetworks; eventually we can deprecate DeployWithNetworks. | 13:56 |
| dimitern | bodie_, it should be possible to have both packages running, since they use different ports for mongo, but i doubt anyone tested this | 13:57 |
| dimitern | rogpeppe, ok, write that in the review pls | 13:57 |
| dimitern | rogpeppe, i'll get to it once mgz lands his state changes | 13:58 |
| rogpeppe | dimitern: ok, will do | 13:58 |
| bodie_ | thanks :) I think I'll wait to make sure the packaged version works before changing anything | 13:58 |
| bodie_ | i've just spent a week trying to get my tests to pass at all | 13:58 |
| bodie_ | so, the fewer degrees of freedom, the better | 13:58 |
| dimitern | bodie_, :) fair enough | 13:58 |
| === vladk is now known as vladk|offline | ||
| wwitzel3 | dimitern: for bug 1294776 does the node itself need to also be 14.04? I upgraded my MAAS provider to 14.04 but I have an all-machines log | 14:18 |
| _mup_ | Bug #1294776: No debug-log with MAAS, 14.04 and juju-core 1.17.5 <logging> <regression> <juju-core:Triaged by wwitzel3> <https://launchpad.net/bugs/1294776> | 14:18 |
| dimitern | wwitzel3, istm you need 1.17.5 juju client bootstrapping on a 14.04 (v1.5 I think?) maas env | 14:20 |
| sinzui | mgz, how goes bug 1291165 ? | 14:20 |
| wwitzel3 | dimitern: yeah, that is what I have .. 14.04 maas, 1.17.5 client, precise node ... I will install a trusty node as well and try it there. | 14:22 |
| dimitern | wwitzel3, if've sure you rebuilt cmd/juju & cmd/jujud before bootstrapping with --upload-tools? | 14:24 |
| mgz | sinzui: doing a little juggling, will try to land today | 14:25 |
| wwitzel3 | dimitern: yeah I removed them before I re-ran go install. | 14:27 |
| sinzui | mgz, wwitzel3 . I think CI will pass the current rev. I will defer your bugs to the next release (which might be tomorrow if your fixes land...or I call it 1.18.0 | 14:29 |
| wwitzel3 | sinzui: thanks for the update | 14:30 |
| mgz | sinzui: that sounds okay | 14:30 |
| perrito666 | Hey I am trying to run script for a test and, at some point the script creates an instance of amazon and tries to run "juju --show-log upgrade-juju -e amazon --version 1.17.6" which fails saying there are no matching tools available, I am running juju from trunk | 14:34 |
| perrito666 | any hints? | 14:34 |
| dimitern | perrito666, better use --debug than --show-log, and put it after the command; you won't need -e envname if "amazon" is your current (juju switch) | 14:40 |
| perrito666 | dimitern: Ill make the changes, altough that is run by the testing script (which is not mine) | 14:41 |
| dimitern | perrito666, then --version is not really needed (unless you want to force a specific version). paste the log you're getting? paste.ubuntu.com | 14:41 |
| perrito666 | dimitern: tx, Ill re run with the debug flag | 14:41 |
| niemeyer | Morning all | 14:41 |
| dimitern | hey niemeyer | 14:42 |
| rogpeppe | niemeyer: hiya | 14:42 |
| wwitzel3 | hi niemeyer | 14:43 |
| niemeyer | Yos! | 14:45 |
| natefinch | rogpeppe: I updated our code with your pastebin, and modified it so it compiles.... I think it's the right translation to actual code, but when we do environs.NewFromAttrs() it says "Environment is not prepared" Which is like... uh, yeah, how can I prepare it before I have it to prepare? | 14:49 |
| natefinch | rogpeppe: the new code: http://paste.ubuntu.com/7125553/ | 14:49 |
| rogpeppe | natefinch: ah, i think you probably need to call environs.Provider(cfg.Type(), and then call prov.Prepare on the provider | 14:51 |
| natefinch | rogpeppe: ahh | 14:51 |
| perrito666 | dimitern: http://paste.ubuntu.com/7125593/ | 14:52 |
| rogpeppe | natefinch: alternatively you could use configstore.NewMem to create a configstore.Storage and call environs.Prepare | 14:53 |
| rogpeppe | natefinch: i'm not sure that's worth doing though | 14:54 |
| perrito666 | dimitern: ignorethe python traceback there | 14:54 |
| mgz | rogpeppe: (or anyone) do you remember where we got to with a juju-level error for doing retries of provider transient issues at the sprint? | 14:55 |
| mgz | we don't seem to have landed anything | 14:55 |
| rogpeppe | mgz: i can't quite remember if we wanted to land that on the providers themselves, or the code that calls them | 14:56 |
| mgz | a bit of both | 14:56 |
| rogpeppe | mgz: did those gobot changes look ok to you in the end, BTW? | 14:57 |
| mgz | rogpeppe: I have some general fears still, but I'm happy to let you try blowing things up :) | 14:58 |
| dimitern | perrito666, are you sure there are actually 1.17.6 tools available? | 14:58 |
| mgz | and have confidence We Can Rebuild It | 14:58 |
| rogpeppe | mgz: i don't do the go get any more in verify, FWIW | 14:58 |
| perrito666 | dimitern: ¯\_(ツ)_/¯ most likely not | 14:58 |
| rogpeppe | mgz: (but i'm sure you saw that) | 14:58 |
| mgz | yeah, last version seemed much less risky | 14:59 |
| dimitern | perrito666, what's this script testing? | 14:59 |
| perrito666 | dimitern: backup/restore | 14:59 |
| perrito666 | For what I see in their jenkins logs they where running this with .5 | 14:59 |
| rogpeppe | mgz: cool. i'll push it and see what happens. | 15:00 |
| perrito666 | perhaps I should try to fetch that rev | 15:00 |
| dimitern | perrito666, I see | 15:06 |
| dimitern | perrito666, try looking in the bucket for what tools are there | 15:07 |
| rogpeppe | oh ffs, you can't do juju set with the output of juju get | 15:14 |
| rogpeppe | that is really crappy behaviour | 15:14 |
| rogpeppe | and the error is really not obvious | 15:14 |
| natefinch | rogpeppe: that is ugly | 15:16 |
| rogpeppe | huh, but... it must've worked before | 15:17 |
| rogpeppe | i must be doing something wrong | 15:17 |
| mgz | rogpeppe: right, it sucks | 15:17 |
| rogpeppe | mgz: ah, no i wasn't doing anything wrong | 15:18 |
| rogpeppe | mgz: yes it does | 15:18 |
| mgz | you need to dedent everything a level and remove all the config junk | 15:18 |
| rogpeppe | mgz: yeah | 15:18 |
| rogpeppe | mgz: i remember going on about this before, but it stayed the same for compatibility reasons | 15:18 |
| rogpeppe | mgz: but having encountered it for real, it really does suck badly | 15:18 |
| * rogpeppe writes a little shim to automate the crappy editing required | 15:19 | |
| natefinch | rogpeppe: do I need to prepare the environment after calling provider.Prepare? provider.Prepare returns an environ... seems like it would be weird to call environs.NewFromAttrs() to make a new environ again | 15:25 |
| rogpeppe | natefinch: no, Prepare prepares the environment, not unsurprisingly | 15:26 |
| natefinch | rogpeppe: ok, so, when the tests run, they're still getting a "environment not prepared" error | 15:26 |
| rogpeppe | natefinch: where are you getting the environment config attributes from? | 15:27 |
| voidspace | natefinch: you were obviously never a boy scout then | 15:27 |
| natefinch | voidspace: I quit after cub scouts, it's true | 15:27 |
| voidspace | "always be prepared"... | 15:27 |
| voidspace | bdum-tish | 15:27 |
| natefinch | rogpeppe: from dummy.sampleconfig | 15:32 |
| rogpeppe | natefinch: right - they need to come from the environment | 15:34 |
| natefinch | rogpeppe: I think they do? http://paste.ubuntu.com/7125800/ | 15:36 |
| natefinch | rogpeppe: full file: http://paste.ubuntu.com/7125804/ | 15:37 |
| rogpeppe | natefinch: no, they don't | 15:37 |
| rogpeppe | natefinch: configs are immutable | 15:37 |
| rogpeppe | natefinch: you need to get the env returned by Prepare and call Config on it to get the config | 15:38 |
| natefinch | rogpeppe: ahh, ok. weird. Sure. | 15:39 |
| dimitern | rogpeppe, updated https://codereview.appspot.com/76910044 - is it better now? | 15:42 |
| rogpeppe | dimitern: looking | 15:42 |
| natefinch | rogpeppe: ok, now the tests are saying environment destroyed, which is progress, sorta. | 15:42 |
| rogpeppe | dimitern: reviewed | 15:45 |
| dimitern | rogpeppe, cheers | 15:48 |
| * dimitern is away for 2h | 15:48 | |
| rogpeppe | mgz: a little workaround for juju's misbehaviour: http://paste.ubuntu.com/7125888/ | 15:53 |
| rogpeppe | mgz: i've named it "juju-set" | 15:53 |
| voidspace | anyone using goimports with vim? | 15:55 |
| natefinch | voidspace: probably a lot of people, but not me :) | 15:56 |
| voidspace | hah | 15:56 |
| voidspace | I'm currently failing to get it working | 15:56 |
| natefinch | voidspace: I had thought it was a drop in replacement for gofmt | 15:57 |
| natefinch | voidspace: haven't actually used it | 15:58 |
| voidspace | natefinch: you have to tell vim to use goimports instead | 15:58 |
| voidspace | and the docs say: For vim, set "gofmt_command" to "goimports": | 15:58 |
| natefinch | voidspace: or just rename it and put it ahead in the path? :) | 15:58 |
| voidspace | but not actually showing how to do that | 15:58 |
| voidspace | natefinch: hah | 15:59 |
| bodie_ | I was just thinking about goimports | 15:59 |
| natefinch | voidspace: linux people are bad at directions. I don't know why | 15:59 |
| bodie_ | would have made my first commit a lot lazier | 15:59 |
| bodie_ | but I don't trust it | 15:59 |
| bodie_ | I had to insert an import by hand into 20 files :P | 16:00 |
| arosales | mgz: fwereade: do you guys have time to sync up with dstroppa on the joyent provider? | 16:00 |
| natefinch | bodie_: I trust it, but I prefer to see the information about imports going into and out of the code... it's important information at times | 16:00 |
| arosales | mgz: fwereade I have a conflict but it would be nice to see where the joyent provider currently is. | 16:00 |
| rogpeppe | mgz: how do i get ssh access to gobot node 0 (so i can run debug-log)? | 16:01 |
| voidspace | ah, to set a variable in .vimrc you don't use set you use let | 16:04 |
| voidspace | now it works | 16:04 |
| rogpeppe | mgz: hmm, | 16:04 |
| rogpeppe | 2014-03-17 11:53:25 INFO juju.worker.uniter context.go:255 HOOK # cd /home/tarmac/gwacl-trees/src/launchpad.net/gwacl; bzr pull --overwrite | 16:04 |
| rogpeppe | 2014-03-17 11:53:25 INFO juju.worker.uniter context.go:255 HOOK Unable to obtain lock held by go-bot@bazaar.launchpad.net on taotie (process #31845), acquired 3 seconds ago. | 16:04 |
| _mup_ | Bug #31845: Debian sync too soon renders uninstallable in dapper <pdp (Ubuntu):Fix Released> <https://launchpad.net/bugs/31845> | 16:04 |
| rogpeppe | 2014-03-17 11:53:25 INFO juju.worker.uniter context.go:255 HOOK See "bzr help break-lock" for more. | 16:04 |
| rogpeppe | 2014-03-17 11:53:25 INFO juju.worker.uniter context.go:255 HOOK bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh://bazaar.launchpad.net/%2Bbranch/gwacl/ | 16:04 |
| perrito666 | brb, lunch | 16:40 |
| rogpeppe | mgz: i'm seeing lots of this kind of thing on the 'bot: http://paste.ubuntu.com/7126134/ | 16:50 |
| rogpeppe | mgz: are the "could not acquire lock" messages expected, or do i need to manually break the lock? | 16:51 |
| sinzui | hi rogpeppe, natefinch : Do either you you have a minute to review this branch that increments the version: https://codereview.appspot.com/78320043 | 16:52 |
| rogpeppe | sinzui: LGTM | 16:53 |
| sinzui | thank you rogpeppe | 16:53 |
| rogpeppe | natefinch: how's it going? | 16:58 |
| natefinch | rogpeppe: I think it's working, our code just expects an instance to have been created, so I have to figure out how to get one of those in the environment (our code call env.Instances) | 17:00 |
| rogpeppe | natefinch: you should be able to call StartInstance on the Environ | 17:01 |
| rogpeppe | natefinch: you could perhaps do that directly after you call Prepare | 17:05 |
| natefinch | rogpeppe: I'm surprised at how hard this is. Is there something that'll return the right StartInstanceParams that'll give me a generic machine? I don't know what fields to fill out, and an empty one just fails. | 17:19 |
| rogpeppe | natefinch: your best bet is to look inside the dummy.StartInstance implementation, i'm afraid | 17:19 |
| rogpeppe | natefinch: i could tell you what to do, but i'd have to do that first... | 17:19 |
| natefinch | rogpeppe: that's fine | 17:20 |
| wwitzel3 | rogpeppe: aww, but I like hand holding, makes me feel safe | 17:21 |
| rogpeppe | wwitzel3: :-) | 17:21 |
| natefinch | rogpeppe, wwitzel3: from the package docs: The configuration YAML for the testing environment must specify a "state-server" property with a boolean value. If this is true, a state server will be started the first time StateInfo is called on a newly reset environment. | 17:31 |
| rogpeppe | natefinch: i think you'll find that there is a state-server property already there | 17:32 |
| natefinch | rogpeppe: yep, it's there and defaulted to true. But calling it returns "dummy environment has not state configured." sigh | 17:34 |
| natefinch | it's like no one's ever actually tried to *use* this package | 17:34 |
| rogpeppe | natefinch: calling what returns that? | 17:35 |
| natefinch | rogpeppe: env.StateInfo() after calling Prepare(). DOcs made it sound like it would start up a dummy state machine. | 17:35 |
| rogpeppe | natefinch: why are you calling StateInfo? | 17:36 |
| natefinch | rogpeppe: "If this is true, a state server will be started the first time StateInfo is called on a newly reset environment." | 17:36 |
| rogpeppe | natefinch: (BTW i'm pretty sure the code i gave you (largely inherited from before) sets state-server to false | 17:37 |
| rogpeppe | natefinch: why do you want a state server? | 17:37 |
| natefinch | rogpeppe: you're right, I missed that it was setting state server to false | 17:37 |
| natefinch | rogpeppe: setting that to true makes StateInfo return "environment is not bootstrapped" which at least makes sense. | 17:37 |
| rogpeppe | natefinch: why are you calling StateInfo? | 17:38 |
| rogpeppe | natefinch: FWIW the docs are out of date - the state server is now started when Bootstrap is called | 17:38 |
| natefinch | rogpeppe: I was trying to find a shortcut around having to write out a whole StartInstanceParam with MachineConfig, since I had no clue as to how to populate them correctly | 17:38 |
| rogpeppe | natefinch: the dummy environment never creates instances unless you call StartInstance | 17:39 |
| rogpeppe | natefinch: if you look in dummy.environ.StartInstance, it looks pretty clear which fields need to be set | 17:39 |
| natefinch | rogpeppe: yes, but it's dumb that I have to look at the implementation to figure out what to set all those things to. Why not just set them for me if they're not set? Like I said, it's like no one has ever actually used this package. | 17:40 |
| rogpeppe | natefinch: looks like MachineNonce, StateInfo.Tag, APIInfo.Tag | 17:40 |
| rogpeppe | natefinch: mostly StartInstance is not called directly, but by higher level code that is expected to set those fields | 17:41 |
| rogpeppe | natefinch: what you're doing is unusual, but i don't think you'll find it's that hard | 17:41 |
| rogpeppe | natefinch: MachineConfig{MachineNonce: "bootstrap-nonce", &state.Info{Tag: "machine-0}, &api.Info{Tag: "machine-0"}} might do the job | 17:42 |
| rogpeppe | natefinch: oh, and MachineId: "0" | 17:43 |
| natefinch | rogpeppe: it needs machineId, too. Yes, it's not hard, I guess I just would have assumed someone would have made a helper method that would just set some reasonable defaults for people who don't care about the particulars of the bootstrap node. | 17:44 |
| rogpeppe | natefinch: if it was done in more than one place, it would be worth doing | 17:44 |
| rogpeppe | natefinch: once upon a time i seriously considered making the dummy environment create an instance at bootstrap time, but it broke loads of tests, so i didn't | 17:45 |
| rogpeppe | natefinch: i guess you could add it as a config option | 17:46 |
| natefinch | rogpeppe: now that I know what to look for, I see several tests are doing this, actually | 17:46 |
| rogpeppe | natefinch: which ones, out of interest? | 17:46 |
| natefinch | rogpeppe: worker/provisioner/kvm-broker_test.go has a startInstance method that does it. same with the lxc broker | 17:47 |
| natefinch | rogpeppe: environs/jujutest/livetests does the same sort of "make up all the fake info and call startinstance" though, modifying it to fail on purpose | 17:49 |
| natefinch | rogpeppe: I guess that's not several, but it's a few | 17:49 |
| rogpeppe | natefinch: the broker tests aren't calling the dummy environ | 17:50 |
| rogpeppe | natefinch: and in the end, there's no really good default for those parameters - they are genuine parameters to the StartInstance call | 17:51 |
| natefinch | rogpeppe: I can make a function that takes a single string for machine id and defaults all the rest of it... that seems pretty defaultable. | 17:52 |
| rogpeppe | natefinch: i guess if you want fake values for APIInfo and StateInfo, and the same nonce for all instances | 17:53 |
| natefinch | rogpeppe: you just make the nonce "foobar-" + machineId | 17:54 |
| natefinch | rogpeppe: Though to be fair, I don't really know what we use the nonce for. | 17:54 |
| rogpeppe | natefinch: it's only used to guard against an extremely unlikely case | 17:55 |
| rogpeppe | natefinch: that will probably never actually happen | 17:55 |
| rogpeppe | natefinch: if the provisioner dies just after it's started the instance but before it's recorded the instance id in the state | 17:55 |
| rogpeppe | natefinch: then when it starts again, it'll start another instance | 17:56 |
| rogpeppe | natefinch: the nonce means that we can know when that old instance connects, that it's not the one we're expecting | 17:56 |
| rogpeppe | natefinch: so for testing purposes, it can be anything tbh | 17:57 |
| rogpeppe | natefinch: i wouldn't be against a testing.FakeMachineConfig(machineId string) *cloudinit.MachineConfig function FWIW | 17:57 |
| natefinch | rogpeppe: I see. Thanks for the explanation. And yeah, that's basically all I really wanted. And maybe something in dummy to start up an environment easily. I just don't want anyone to have to go through my pain again. | 17:59 |
| rogpeppe | natefinch: BTW i'm seeing replicaset test failures in the 'bot: https://code.launchpad.net/~rogpeppe/juju-core/521-peergrouper-publish/+merge/211785/comments/500728/+download | 17:59 |
| natefinch | rogpeppe: that's annoying and sucky. I haven't really had a chance to go back and try to make them more reliable. | 18:01 |
| * rogpeppe is done for the day | 18:03 | |
| perrito666 | such is my luck, found a bug by fixing another :p | 18:03 |
| natefinch | rogpeppe: btw, there's juju/testing/instance.go which has a StartInstance method that takes an environment and a machineid :) It doesn't quite work, but it's close | 18:04 |
| natefinch | s/method/function/ | 18:04 |
| rogpeppe | natefinch: ah, i guess it needs tools | 18:05 |
| natefinch | rogpeppe: yep | 18:05 |
| rogpeppe | natefinch: i think you'll find that's more hassle than it's worth | 18:06 |
| natefinch | rogpeppe: probably | 18:06 |
| perrito666 | hey what is under cmd/plugins, it it made by us too? | 18:10 |
| perrito666 | I see that restore backup seems to be re-implementing ssh and scp which are under utils | 18:10 |
| natefinch | perrito666: yeah, it's made by us. I'm not entirely sure why it's reimplementing those things | 18:14 |
| perrito666 | natefinch: apparently it is reimplementing scp without using the identity file from ~/.juju which fails, at least on ec2 with a very sad and undescriptive error :p | 18:15 |
| natefinch | perrito666: bzr blame to figure out who to complain to ;) | 18:16 |
| mfoord | rogpeppe: well done on fixing the bot :-) | 18:17 |
| perrito666 | natefinch: roger.p but I am not sure if he is the author or just someone who moved stuff | 18:18 |
| natefinch | perrito666: I think roger wrote at least some of it. send an email to juju-dev@lists.ubuntu.com if you want more information, I think most of the UK guys are out for the day by now. | 18:20 |
| perrito666 | natefinch: what would be roger.p name expanded? :p | 18:34 |
| natefinch | perrito666: sorry, Roger Peppe, aka rogpeppe on irc | 18:34 |
| natefinch | perrito666: he's in the UK. | 18:34 |
| perrito666 | ah I should have figured that on my own (who he is, not where) | 18:34 |
| natefinch | perrito666: it's ok, there's a lot of people on the team | 18:35 |
| wwitzel3 | done for the day | 19:31 |
| thumper | o/ | 19:42 |
| natefinch | thumper: morning | 19:47 |
| wwitzel3 | hey thumper | 19:47 |
| * thumper is off to a physio appt | 20:20 | |
| === thumper is now known as thumper-physio | ||
| === BradCrittenden is now known as bac | ||
| thumper-physio | mramm: ping | 21:05 |
| === thumper-physio is now known as thumper | ||
| thumper | sinzui: how close are you to writing the release notes? | 21:08 |
| thumper | sinzui: I should write up something on the proxy support | 21:09 |
| sinzui | thumper, streams.canonical.com did not update, so the release is stalled. | 21:09 |
| sinzui | you can add to https://docs.google.com/a/canonical.com/document/d/1CAN-tmQYGLdy1Dd6Ra13EjzqYDivfVZnwRhTfjAdlOQ/edit | 21:09 |
| sinzui | and I can revise if needed | 21:10 |
| thumper | ok, will do now | 21:10 |
| thumper | sinzui: can you make it so I can edit? | 21:10 |
| sinzui | oops | 21:10 |
| sinzui | thumper, reload | 21:11 |
| thumper | ta | 21:11 |
| bodie_ | I want to make sure I understand this bit about dynamic type. | 21:11 |
| bodie_ | http://golang.org/ref/spec#Type_assertions | 21:11 |
| bodie_ | the phrasing of this is kind of unclear. | 21:11 |
| bodie_ | "x.(T) => "asserts that the dynamic type of x is identical to the type T."" | 21:12 |
| bodie_ | I thought Go didn't have dynamic types at all | 21:12 |
| bodie_ | therefore, isn't this really saying: "interfaces are a container type; empty interfaces are satisfied by all types, and so can contain any type" | 21:12 |
| bodie_ | so it's not REALLY dynamic, just.... virtually dynamic. | 21:17 |
| thumper | bodie_: x needs to be an interface | 21:17 |
| bodie_ | yeah | 21:17 |
| bodie_ | the phrase "dynamic type of x" threw me off, I guess | 21:18 |
| thumper | sinzui: can you look over the addition there? | 21:20 |
| thumper | sinzui: actually, time to write some more | 21:20 |
| sinzui | I will | 21:20 |
| thumper | sinzui: look ok? also added a section for lxc-clone | 21:29 |
| sinzui | I see | 21:29 |
| sinzui | thumper, this is all goos | 21:32 |
| sinzui | good | 21:32 |
| thumper | cool | 21:33 |
| perrito666 | sinzui: ping? | 22:01 |
| sinzui | perrito666, hello | 22:03 |
| perrito666 | have a moment for me? | 22:03 |
| sinzui | Maybe in 15 minutes | 22:03 |
| perrito666 | sinzui: no hurry, it can wait | 22:03 |
| perrito666 | thank you | 22:03 |
| === vladk|offline is now known as vladk | ||
| === marrusl is now known as marrusl_afk | ||
| === marrusl_afk is now known as marrusl | ||
| sinzui | hi perrito666 | 22:21 |
| perrito666 | ji, sorry for the impolite ping instead of hello, I was paying attention at something else | 22:21 |
| perrito666 | say, I am working in https://bugs.launchpad.net/juju-core/+bug/1291022 | 22:22 |
| _mup_ | Bug #1291022: Cannot restore a state-server on ec2 and openstack <backup-restore> <ec2-provider> <hp-cloud> <regression> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1291022> | 22:22 |
| * sinzui nods | 22:22 | |
| perrito666 | sinzui: yet, I am getting completely different errors :| | 22:23 |
| perrito666 | http://pastebin.ubuntu.com/7127660/ | 22:23 |
| perrito666 | can you tell me the specs of the installation where you ran the restore that you pasted on the ticket? | 22:23 |
| perrito666 | It would seem that it goes trough machine 0 setup and it blows on machine 1 | 22:24 |
| * perrito666 wonders if anyone ever managed to restore an ec2 using this | 22:24 | |
| sinzui | perrito666, 1. you get the crucial error I see when working with hp or aws | 22:24 |
| sinzui | perrito666, The instrumentation of failure might be different because of the credentials and my version of euca/nova? | 22:25 |
| sinzui | perrito666, the specs? do you mean the env.yaml I used | 22:26 |
| perrito666 | sinzui: 1) ah I thought that was part of the test given the message on line 155 | 22:27 |
| fwereade | thumper, you know the uniter/debug timeouts -- I have a paste that says where they are when they timeout, in case you don't and it rings any bells: http://paste.ubuntu.com/7127717/ | 22:28 |
| sinzui | perrito666, This cam from juju. I saw it on my command line for hp and ec2. I put the test into juju CI anyway wondering if I had a local setup problem: | 22:29 |
| sinzui | error: cannot restore bootstrap machine: cannot get public address of bootstrap machine: machine "0" has no public address | 22:29 |
| sinzui | perrito666, juju did standup a state server though. you can even get the status if it. | 22:29 |
| perrito666 | sinzui: I encountered some other issues (besides yours) that is what puzzled me | 22:29 |
| sinzui | maybe juju is impatient. the public address will be available if it waits a little longer | 22:30 |
| perrito666 | sinzui: I think that is the problem, perhaps a race condition, altough, after that there is another bug which I solved on my local version :) | 22:30 |
| perrito666 | so you would not have arrived much further | 22:30 |
| perrito666 | perhaps it works here bc of the lag to the server | 22:31 |
| perrito666 | sinzui: http://pastebin.ubuntu.com/7127730/ | 22:31 |
| sinzui | that's promising | 22:32 |
| fwereade | perrito666, sinzui: fwiw we obviously *do* have that public address *somewhere* because we just sshed to it -- can we get it from there, instead of whatever we're using to look it up that's racy/faily? | 22:32 |
| perrito666 | fwereade: I think the issue is different | 22:33 |
| perrito666 | fwereade: I am in south américa and my connection to amazon is rather slow :) that gives the machine time to be provisioned and get an ip | 22:33 |
| fwereade | perrito666, fwiw I have certainly run backup/restore against ec2, and seen it work, in the past | 22:33 |
| perrito666 | fwereade: my guess if that even if we could get hold of the ip (which I think we can) we would need to wait anyway | 22:34 |
| perrito666 | fwereade: well, running 1.7.6 here I found out that restore reimplements ssh/scp but omits to use identity file | 22:35 |
| perrito666 | at least in the context of the test, where an id_rsa is created for it | 22:35 |
| fwereade | perrito666, ha, good catch | 22:35 |
| fwereade | perrito666, that's worth a fix independent of anything else | 22:35 |
| perrito666 | other parts use utils/ssh which does use the right id_rsa and work | 22:35 |
| perrito666 | so for the sake of fixing this particular issue I hardcoded a few things on my local version to see if I could get to the end of the actual restore | 22:35 |
| === vladk is now known as vladk|offline | ||
| fwereade | perrito666, am I right in thinking that it's the rsyslog stuff that's failing there on machine 1? | 22:39 |
| fwereade | perrito666, but regardless, that "need to wait anyway" is interesting,expand please? | 22:39 |
| perrito666 | sorry I was tending the laundry | 22:41 |
| perrito666 | fwereade: well, I was not able to reproduce the actual error reported by sinzui | 22:41 |
| sinzui | perrito666, Since I have never seen a pass of my test, there are some lines that I assume will work. If the exit code of the restore is 0, the script calls status until it sees all the machines and unit agents have started. That has a 10 minute timeout. | 22:41 |
| perrito666 | I need to look into it but I guess that -> cannot get public address of bootstrap machine: machine "0" has no public address | 22:43 |
| sinzui | perrito666, you have an error none-the-less. juju-backup exited and stated the update failed | 22:43 |
| perrito666 | means that it has to wait a bit more since the only difference between me and the test machines is a extrmely poor connection | 22:43 |
| perrito666 | I will take a deeper look | 22:44 |
| sinzui | perrito666, this is the test run from a few hours ago: http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/functional-backup-restore-devel/86/console | 22:44 |
| perrito666 | sinzui: I do get the connection error, which is strange because after that all marks success | 22:46 |
| perrito666 | well back to the research then :) I guess Ill tackle those one by one I only wish the test would not take so long | 22:47 |
| perrito666 | sinzui: thank you you have been very helfpul | 22:52 |
| perrito666 | fwereade: btw, aren't you on holiday | 22:57 |
| perrito666 | or was that yesterday? | 22:57 |
| fwereade | perrito666, that was yesterday :) | 22:57 |
| perrito666 | agh, that always happens to me when I work from home | 22:58 |
| fwereade | perrito666, it's ok, I'm actually programming this evening, and that makes me happy | 22:59 |
| fwereade | perrito666, it must be late for you too ;p | 22:59 |
| perrito666 | well, I am debugging, which makes me happy, so we are all happy | 22:59 |
| perrito666 | fwereade: yes it is almos 8pm | 22:59 |
| perrito666 | got caught with this bug | 23:00 |
| fwereade | perrito666, if you're still around when axw shows up he might have something useful to say about the rsyslog complaints on machine 1 | 23:00 |
| fwereade | perrito666, maybe drop him an email when you stop if he's not around yet | 23:00 |
| perrito666 | fwereade: sure, can you translate axw into a real name.lastname :p ? | 23:00 |
| fwereade | perrito666, ha, sorry, it's andrew wilkins | 23:01 |
| * fwereade thinks, and has a sudden crisis of faith | 23:01 | |
| * fwereade was right | 23:01 | |
| davecheney | pop quiz: is floating point a valid configuration value type | 23:32 |
| davecheney | marco-traveling: and I think no | 23:32 |
| davecheney | would anyone care to refute that point ? | 23:32 |
| davecheney | thumper: https://bugs.launchpad.net/juju-core/+bug/1295420 | 23:48 |
| _mup_ | Bug #1295420: local environment does not survive reboot on ppc64el <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1295420> | 23:48 |
| davecheney | ^ i'm confused about this one | 23:48 |
| davecheney | the units appear to be up | 23:48 |
| davecheney | and there is no indicatoin that they are looping trying to reconnect | 23:48 |
| davecheney | in their logs | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!