[00:08] <stokachu> anyone know what "juju.container interface.go:55 unused config option: "use-clone" -> "false"" is referring to?
[00:12] <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:14] <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:15] <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:16] <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:17] <sinzui> stokachu, I think the clone issue is just juju being verbose
[00:18] <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:19] <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:26] <thumper> stokachu: the fact that it is showing up is a bug
[00:26] <thumper> stokachu: it shouldn't be
[00:27]  * thumper thinks...
[00:27] <thumper> yeah
[00:27] <thumper> it should omit it if it isn't there
[00:28] <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:29] <stokachu> ah ok
[00:29] <stokachu> so with that said im trying to get the kvm instances deployed with a --constraints mem=1G
[00:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <thumper> sure...
[00:36]  * thumper hands stokachu an award
[00:36] <stokachu> lol
[00:36] <thumper> however...
[00:37] <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:38] <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:39] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <sinzui> bodie_, lbox propose -cr
[00:50] <stokachu> thumper: http://paste.ubuntu.com/7122907/
[00:51] <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:52] <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:53] <bodie_> sigh
[00:53] <sinzui> bodie_, just push the updates, Lp will see the change and update the diff
[00:54] <bodie_> :) looks like very few conflicts
[00:54] <bodie_> ok
[00:55]  * 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:56] <wallyworld> thumper: i just tail the log file in ~tarmac/logs
[00:57] <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:58] <sinzui> bodie_, that right, merge trunk. the conflicts will be listed edit each file then use `bzr resolve` then `bzr commit`
[00:59] <bodie_> ok
[01:08] <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:09] <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:12] <waigani> thumper: landed!
[01:19] <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:20] <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:21] <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:22] <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:23] <stokachu> testing the trusted wordpress+mysql deployment :X
[01:24] <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:32] <stokachu> sweet
[01:32] <stokachu> thumper: http://paste.ubuntu.com/7123027/
[01:32] <stokachu> works
[01:33] <thumper> stokachu: awesome
[01:38] <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:39] <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:42] <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:43] <stokachu> thumper: i guess my last question is should i keep my findings to myself? :)
[01:44] <thumper> stokachu: no
[01:45] <stokachu> cool, i was thinking about a blog post but with a huge disclaimer lol
[01:49] <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:51] <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:52] <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:53] <waigani> thumper: ping
[01:53] <thumper> waigani: ya
[01:53] <waigani> pmed you
[01:54] <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:55] <axw> sinzui: there should be a "Running script on..." line before any of the apt-get, etc. feedback
[01:57] <thumper> bodie_: mostly
[01:57] <thumper> yes
[02:02] <bodie_> all righty
[02:07] <sinzui> axw, I attached the debug log to the bug
[02:07] <axw> sinzui: thanks
[02:08] <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:23] <thumper> axw: approved
[02:25] <axw> thumper: thanks, just fixing ssh now...
[02:29] <thumper> sinzui: I just want to confirm something
[02:29] <thumper> sinzui: our trusty CI tests have trusty bootstrap nodes, yes?
[02:30] <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:31] <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:32] <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:33] <thumper> hmm...
[02:33] <wallyworld> eg you deploy cs:trusty/myql
[02:33] <wallyworld> it looks for a trusty image
[02:34] <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:35] <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:36] <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:37] <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:38] <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:39] <sinzui> well I can deploy again and see if it works
[02:39] <wallyworld> turn it off and on again
[02:40] <wallyworld> thumper: the default fallback arch could be amd64, or it could be an env config just like "default-series" is
[02:41] <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:42] <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:48] <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:49] <wallyworld> at least that explains it
[02:54] <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:55] <thumper> sinzui: me neither
[02:55] <thumper> sinzui: it is an ec2 issue?
[02:55] <thumper> or was it a tools sync issue?
[02:56] <sinzui> I used streams
[02:57] <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
[03:05] <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:09] <thumper> boo yeah
[03:10] <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:11] <wallyworld> thumper: reviewed with bikeshed
[03:11] <thumper> you know how much I love bikesheds
[03:12] <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:13]  * thumper goes to make coffee
[03:28] <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:45] <thumper> wallyworld: I have time
[03:45] <wallyworld> ok, ta
[04:30] <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:34] <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:35] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <thumper> wallyworld: I prefer pass by reference
[04:45] <thumper> can't be nil
[04:45] <thumper> in C++
[04:46] <wallyworld> true
[05:07]  * axw enjoys not having to think too much about object ownership
[06:15] <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:16] <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
[08:06] <vladk> good morning
[08:11] <dimitern> morning vladk
[08:16] <rogpeppe> dimitern, vladk: mornin'
[08:16] <dimitern> hey rogpeppe :)
[08:24] <dimitern> thumper-afk, when you can please check cadmin, I filled some leave for approval
[08:29] <jam1> morning dimitern, rogpeppe
[08:29] <rogpeppe> jam1: hiya
[08:30] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:48] <jam1> rogpeppe: hopefully one final review of https://codereview.appspot.com/76120044/ ?
[08:49] <rogpeppe> jam1: already done
[08:50] <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:52] <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:53] <jam1> now, I *can* telnet localhost 37017
[08:53] <jam1> but I don't think anything is actually running there
[08:54] <jam1> ahh... hmmm. mongod is still running
[08:54] <jam1> and destroy-environment --force isn't killing it
[08:55] <dimitern> rogpeppe, reviewed
[08:55] <rogpeppe> dimitern: ta!
[08:57] <dimitern> mgz, how's it going with https://codereview.appspot.com/77270046/ ?
[08:58] <sparkiegeek> jam1: so that moved me a little further along, but now I get http://paste.ubuntu.com/7124257/
[08:59] <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.
[09:00] <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:01] <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:02] <rogpeppe> jam1: (at least, i did last time i looked)
[09:12] <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:13] <jam1> rogpeppe: yes
[09:17] <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:18] <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:21] <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:22] <rogpeppe> axw: looking
[09:23] <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:33] <wwitzel3> hello
[09:42] <rogpeppe> axw: reviewed
[09:42] <axw> rogpeppe: thanks
[09:45] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:58] <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:59] <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
[10:00] <jam> rogpeppe, wwitzel3, dimitern, waigani: standup time
[10:02] <rogpeppe> vladk: ^
[10:02] <rogpeppe> https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.sbtpoheo4q7i7atbvk9gtnb3cc
[10:03] <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:06] <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:07] <rogpeppe> voidspace: there's a meeting currently
[10:07] <rogpeppe> voidspace: see above
[10:07] <voidspace> ah
[10:08] <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:09] <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:45] <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:46] <perrito666> dimitern: nothing that has panic on the title can be nice and tiny :p
[10:47] <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:52] <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:55] <perrito666> to test things with ec2, do we have an amazon account purposed for testing or should I use my own?
[10:56] <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:57] <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:58] <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:59] <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
[11:00] <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:01] <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:03] <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:04] <wwitzel3> dimitern: I have to get it setup a bit first, as my local maas is running precise
[11:05] <wwitzel3> dimitern: but that shouldn't take took long
[11:05] <dimitern> wwitzel3, np
[11:07] <rogpeppe> wallyworld: so does something like this look plausible? http://paste.ubuntu.com/7124711/
[11:07] <wallyworld> looking
[11:08] <wallyworld> rogpeppe: almost. the tools metadata is generated off tarballs, not just jujud. so we need to add a tar step
[11:09] <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:10] <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:11] <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:12] <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:13] <wallyworld> but if we get rid of upload tools, i agree 100% we need to add tooling support
[11:14] <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:15] <wallyworld> rogpeppe: the release scripts are hosted on lp, i can't recall the branch name right now
[11:17] <wallyworld> fwereade: if you wanted a quick hangout to clarify the branch, i can do that. ping me when you are redy
[11:18] <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:31] <rogpeppe> mgz: does this look reasonable as a gobot config setting? http://paste.ubuntu.com/7124775/
[11:34] <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:36] <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:37] <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:38] <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:39] <mgz> hey everyone, come modify juju-core
[11:39] <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:40] <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:41] <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:42] <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:43] <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:44] <rogpeppe> jam: so is the "go get -u .../juju-core/...
[11:44] <rogpeppe> "
[11:45] <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:46] <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:47] <rogpeppe> jam: i don't think it requires any changes to the charm
[11:49]  * perrito666 wishes he would stop writing git pull when he tries to bzr pull
[11:51] <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:52] <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:53] <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:54] <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
[12:10] <rogpeppe> dimitern: i've made (almost) all the changes pwd
[12:10] <rogpeppe> dimitern: ignore me for the moment
[12:13] <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:14] <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:15] <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:16] <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:17] <bodie_> Understand, what's missing for me to be fully set up?
[12:18] <bodie_> Rietveld?
[12:18] <perrito666> mgz: again, my ubuntu server :p
[12:20] <rogpeppe> natefinch: ping
[12:20] <fwereade> bodie_, in one of the docs -- possibly CONTRIBUTING? it describes lbox setup
[12:21] <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:22] <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:23] <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:25] <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:26] <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:27] <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:28] <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:29] <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:31] <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:32] <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:35] <dimitern> rogpeppe, i was mostly concerned with not using statetesting
[12:36] <dimitern> rogpeppe, LGTM
[12:37] <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:38] <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:39] <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:40] <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:42] <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:49] <fwereade> mgz, can you handle the joyent call tonight? I need to stop a bit early
[12:49] <mgz> fwereade: sure
[12:55] <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/
[13:07] <dimitern> rogpeppe, do you have time to look at https://codereview.appspot.com/76910044 ?
[13:08] <rogpeppe> dimitern: am currently pairing with voidspace; should be able to have a look later.
[13:08] <dimitern> rogpeppe, ok then
[13:32] <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:33] <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:34] <dimitern> rogpeppe, hence the new API call - we can test whether it's supported
[13:35] <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:36] <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:37] <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:38] <bodie_> should I open a bug report for the issue?
[13:40] <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:41] <dimitern> bodie_, please file one, yes
[13:41] <bodie_> I know natefinch and a couple of others were discussing this yesterday
[13:42] <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:43] <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:45] <rogpeppe> dimitern: ok, i guess that's fair enough
[13:46] <rogpeppe> dimitern: i don't see why we don't make DeployWithNetworks backwardly compatible with Deploy though
[13:47] <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:48] <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:49] <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:50] <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:51] <bodie_> all good, I got my remote working so I'm happy
[13:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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
[14:18] <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:20] <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:22] <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:24] <dimitern> wwitzel3, if've sure you rebuilt cmd/juju & cmd/jujud before bootstrapping with --upload-tools?
[14:25] <mgz> sinzui: doing a little juggling, will try to land today
[14:27] <wwitzel3> dimitern: yeah I removed them before I re-ran go install.
[14:29] <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:30] <wwitzel3> sinzui: thanks for the update
[14:30] <mgz> sinzui: that sounds okay
[14:34] <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:40] <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:41] <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:42] <dimitern> hey niemeyer
[14:42] <rogpeppe> niemeyer: hiya
[14:43] <wwitzel3> hi niemeyer
[14:45] <niemeyer> Yos!
[14:49] <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:51] <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:52] <perrito666> dimitern: http://paste.ubuntu.com/7125593/
[14:53] <rogpeppe> natefinch: alternatively you could use configstore.NewMem to create a configstore.Storage and call environs.Prepare
[14:54] <rogpeppe> natefinch: i'm not sure that's worth doing though
[14:54] <perrito666> dimitern: ignorethe python traceback there
[14:55] <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:56] <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:57] <rogpeppe> mgz: did those gobot changes look ok to you in the end, BTW?
[14:58] <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:59] <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
[15:00] <rogpeppe> mgz: cool. i'll push it and see what happens.
[15:00] <perrito666> perhaps I should try to fetch that rev
[15:06] <dimitern> perrito666, I see
[15:07] <dimitern> perrito666, try looking in the bucket for what tools are there
[15:14] <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:16] <natefinch> rogpeppe: that is ugly
[15:17] <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:18] <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:19]  * rogpeppe writes a little shim to automate the crappy editing required
[15:25] <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:26] <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:27] <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:32] <natefinch> rogpeppe: from dummy.sampleconfig
[15:34] <rogpeppe> natefinch: right - they need to come from the environment
[15:36] <natefinch> rogpeppe: I think they do?  http://paste.ubuntu.com/7125800/
[15:37] <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:38] <rogpeppe> natefinch: you need to get the env returned by Prepare and call Config on it to get the config
[15:39] <natefinch> rogpeppe: ahh, ok.  weird. Sure.
[15:42] <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:45] <rogpeppe> dimitern: reviewed
[15:48] <dimitern> rogpeppe, cheers
[15:48]  * dimitern is away for 2h
[15:53] <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:55] <voidspace> anyone using goimports with vim?
[15:56] <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:57] <natefinch> voidspace:  I had thought it was a drop in replacement for gofmt
[15:58] <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:59] <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
[16:00] <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:01] <rogpeppe> mgz: how do i get ssh access to gobot node 0 (so i can run debug-log)?
[16:04] <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:40] <perrito666> brb, lunch
[16:50] <rogpeppe> mgz: i'm seeing lots of this kind of thing on the 'bot: http://paste.ubuntu.com/7126134/
[16:51] <rogpeppe> mgz: are the "could not acquire lock" messages expected, or do i need to manually break the lock?
[16:52] <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:53] <rogpeppe> sinzui: LGTM
[16:53] <sinzui> thank you rogpeppe
[16:58] <rogpeppe> natefinch: how's it going?
[17:00] <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:01] <rogpeppe> natefinch: you should be able to call StartInstance on the Environ
[17:05] <rogpeppe> natefinch: you could perhaps do that directly after you call Prepare
[17:19] <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:20] <natefinch> rogpeppe: that's fine
[17:21] <wwitzel3> rogpeppe: aww, but I like hand holding, makes me feel safe
[17:21] <rogpeppe> wwitzel3: :-)
[17:31] <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:32] <rogpeppe> natefinch: i think you'll find that there is a state-server property already there
[17:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <rogpeppe> natefinch: MachineConfig{MachineNonce: "bootstrap-nonce", &state.Info{Tag: "machine-0}, &api.Info{Tag: "machine-0"}} might do the job
[17:43] <rogpeppe> natefinch: oh, and MachineId: "0"
[17:44] <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:45] <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:46] <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:47] <natefinch> rogpeppe: worker/provisioner/kvm-broker_test.go   has a startInstance method that does it.  same with the lxc broker
[17:49] <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:50] <rogpeppe> natefinch: the broker tests aren't calling the dummy environ
[17:51] <rogpeppe> natefinch: and in the end, there's no really good default for those parameters - they are genuine parameters to the StartInstance call
[17:52] <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:53] <rogpeppe> natefinch: i guess if you want fake values for APIInfo and StateInfo, and the same nonce for all instances
[17:54] <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:55] <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:56] <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:57] <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:59] <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
[18:01] <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:03]  * rogpeppe is done for the day
[18:03] <perrito666> such is my luck, found a bug by fixing another :p
[18:04] <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:05] <rogpeppe> natefinch: ah, i guess it needs tools
[18:05] <natefinch> rogpeppe: yep
[18:06] <rogpeppe> natefinch: i think you'll find that's more hassle than it's worth
[18:06] <natefinch> rogpeppe: probably
[18:10] <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:14] <natefinch> perrito666: yeah, it's made by us.  I'm not entirely sure why it's reimplementing those things
[18:15] <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:16] <natefinch> perrito666: bzr blame to figure out who to complain to ;)
[18:17] <mfoord> rogpeppe: well done on fixing the bot :-)
[18:18] <perrito666> natefinch: roger.p but I am not sure if he is the author or just someone who moved stuff
[18:20] <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:34] <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:35] <natefinch> perrito666: it's ok, there's a lot of people on the team
[19:31] <wwitzel3> done for the day
[19:42] <thumper> o/
[19:47] <natefinch> thumper: morning
[19:47] <wwitzel3> hey thumper
[20:20]  * thumper is off to a physio appt
[21:05] <thumper-physio> mramm: ping
[21:08] <thumper> sinzui: how close are you to writing the release notes?
[21:09] <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:10] <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:11] <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:12] <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:17] <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:18] <bodie_> the phrase "dynamic type of x" threw me off, I guess
[21:20] <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:29] <thumper> sinzui: look ok? also added a section for lxc-clone
[21:29] <sinzui> I see
[21:32] <sinzui> thumper, this is all goos
[21:32] <sinzui> good
[21:33] <thumper> cool
[22:01] <perrito666> sinzui: ping?
[22:03] <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:21] <sinzui> hi perrito666
[22:21] <perrito666> ji, sorry for the impolite ping instead of hello, I was paying attention at something else
[22:22] <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:23] <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:24] <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:25] <sinzui> perrito666, The instrumentation of failure might be different because of the credentials and my version of euca/nova?
[22:26] <sinzui> perrito666, the specs? do you mean the env.yaml I used
[22:27] <perrito666> sinzui: 1) ah I thought that was part of the test given the message on line 155
[22:28] <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:29] <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:30] <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:31] <perrito666> perhaps it works here bc of the lag to the server
[22:31] <perrito666> sinzui:  http://pastebin.ubuntu.com/7127730/
[22:32] <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:33] <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:34] <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:35] <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:39] <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:41] <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:43] <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:44] <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:46] <perrito666> sinzui: I do get the connection error, which is strange because after that all marks success
[22:47] <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:52] <perrito666> sinzui: thank you you have been very helfpul
[22:57] <perrito666> fwereade: btw, aren't you on holiday
[22:57] <perrito666> or was that yesterday?
[22:57] <fwereade> perrito666, that was yesterday :)
[22:58] <perrito666> agh, that always happens to me when I work from home
[22:59] <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
[23:00] <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:01] <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:32] <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:48] <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