[00:00] <axw> katco: thanks, sorry about that. little bit of rain and the network goes out
[00:01] <rick_h_> thumper: good time off?
[00:01] <thumper> rick_h_: yeah, a real nice break
[00:01] <thumper> rick_h_: didn't get all I wanted to get done done...
[00:02] <thumper> but them's the breaks
[00:02] <rick_h_> thumper: never do
[00:02] <thumper> the kids have decided they like D&D
[00:02] <rick_h_> lol
[00:02] <thumper> and I'm kinda required as a DM
[00:02] <thumper> which takes time...
[00:02] <rick_h_> but of course
[00:02] <katco> thumper: awesome!
[00:02] <rick_h_> to do properly
[00:02] <katco> axw: no worries at all
[00:02] <rick_h_> thumper: have time today for me to bug you with a few notes on things?
[00:02] <thumper> they were real frustrated that I had to read up on the campaign first
[00:02] <rick_h_> lol, yea been a long time here
[00:03] <rick_h_> I'd have to go reread a lot of stuff heh
[00:03] <thumper> rick_h_: yeah, at a cafe now so I can focus on design without kids around
[00:03] <thumper> the rules changed since I last played
[00:03] <thumper> over 20 years ago
[00:03] <axw> thumper: nice :)  I never had anyone interested in playing D&D growing up
[00:04] <rick_h_> thumper: k, ping if you get free/bandwidth and if not will bring it up later but had some things come up friday/today figured I'd mention
[00:04] <katco> axw: same here.... somehow i was a huge nerd and never played even once
[00:04] <axw> steve jackson books were there for me though
[00:04] <thumper> rick_h_: need to mention with voice? or irc would work?
[00:04] <rick_h_> thumper: we can try irc if you want
[00:05] <thumper> rick_h_: my mind is pretty good at reading your writing in your voice
[00:05] <rick_h_> lol awesome
[00:05] <thumper> can also pick up most of the sarcasm
[00:05] <thumper> :)
[00:06] <thumper> rick_h_: if we find it now working, we could do a call later
[00:06] <rick_h_> thumper: here, PM, or other side?
[00:06] <thumper> rick_h_: if it is sensitive PM or other
[00:06] <thumper> otherwise, I'm fine here
[00:06] <rick_h_> I don't think it is but do that just to be safe I guess
[00:06] <thumper> sure
[00:13] <axw> katco: it's JUJU_DEV_FEATURE_FLAGS
[00:13] <axw> you're missing the "DEV"
[00:21] <katco> axw: thx
[00:23] <axw> katco: left a few more comments. all the panics need to go, and init needs to move, otherwise trivials/suggestions
[00:23] <katco> axw: yeah i was going to ask about the panics... wasn't quite sure what to do there
[00:23] <katco> axw: i think i ran into a circular reference last time i tried to address the registration? i'll let you know here in a sec
[00:24] <axw> katco: there should be no references from storage->openstack, only the reverse
[00:29] <katco> axw: i see my misunderstanding... i think i was trying to register it in storage/provider/ something or other
[00:38] <katco> axw: thanks for the great reviews. fresh PR up.
[00:42] <rick_h_> and like that you can ruin someone else's day bwuhahaha :)
[00:42] <thumper> katco: it was suggested that without the _DEV_ bit, it would be too tempting for clients to try to use them in prod settings
[00:42] <thumper> which they would do
[00:43] <katco> thumper: i completely agree with that lol
[00:52] <rick_h_> thumper: I forgot a dinner tomorrow, can I move out sync back a few hours?
[00:52] <thumper> rick_h_: back as in later...?
[00:52] <rick_h_> thumper: yes
[00:52] <rick_h_> later in the day 3hrs
[00:53] <thumper> 3.5?
[00:53] <thumper> or is that too later?
[00:53] <rick_h_> that's peachy
[00:53] <thumper> ok
[00:53]  * thumper moves
[00:53] <rick_h_> aunt's b-day, not on my work calendar doh!
[00:53] <thumper> :)
[00:54] <axw> katco: thanks, LGTM with a few more small fixes
[00:54] <katco> axw: k thx... getting the dummy charm to allocate some storage will be a milestone
[00:55] <axw> katco: did you see the email I sent out, with the reference to the hacked version of postgresql?
[00:55] <axw> katco: or did you just want to test with something a bit leaner?
[00:56] <katco> axw: just wanted to start lean so i can iterate quickly
[00:56] <axw> sure, SGTM
[00:56] <katco> axw: i will move onto postgres afterwards since i know that's what we would like to demo with
[00:56] <axw> good practice to write charms anyway :)
[00:56] <katco> axw: haha yeah :)
[01:12] <cherylj> hey axw, do you know how to get the output of the cloudinit script like is in bug 1439447?
[01:12] <mup> Bug #1439447: tools download in cloud-init should not go through http[s]_proxy <cloud-installer> <landscape> <juju-core:In Progress by cherylj> <juju-core 1.23:In Progress by cherylj> <https://launchpad.net/bugs/1439447>
[01:13] <axw> cherylj: one moment, I think I know, just checking
[01:15] <axw> cherylj: the instance's cloud-config is /var/lib/cloud/instance/cloud-config.txt
[01:15] <axw> it's not exactly a shell script, but has each of the commands in a YAML file
[01:15] <cherylj> axw: Awesome, thanks!!
[01:15] <axw> nps
[01:17] <axw> cherylj: BTW regarding your last comment on that bug: yes, there will almost certainly be people that want it either way. In particular, manually provisioned machines may need to go through a proxy
[01:17] <axw> I think otherwise they'd be going direct tho
[01:18] <thumper> axw: yeah... kinda hard to deal with that where we have a mixed environent
[01:18] <thumper> unsure just yet
[01:19] <cherylj> axw: Thanks, providing an option is proving to be a bit difficult to implement.
[01:36] <axw> thumper cherylj: I was just thinking, don't we currently expect all nodes to communicate directly? for the API anyway?
[01:36] <axw> so... maybe just disabling the proxy isn't a problem
[01:37] <axw> I think even for manual we require things to be directly routable atm
[01:37] <thumper> that was my reasoning too
[01:41] <cherylj> axw, thumper:   cool, so I'll just disable the proxy when we're downloading tools for the non-bootstrap node
[01:41] <natefinch> weird, just got disconnected
[01:42] <thumper> natefinch: I just assumed you were done :)
[01:42] <axw> cherylj: sounds good. I can't recall if there's any case where a non-bootstrap node downloads tools directly from the Internet, but if so then don't disable for that
[01:42] <axw> cherylj: I don't *think* there is such a case though
[01:42] <natefinch> thumper: not quite :)
[01:43] <thumper> axw: we were looking at ONLY changing the curl command for acquiring tools
[01:43] <cherylj> axw: yeah, I don't think there is
[01:43] <thumper> axw: there is a command line option '--noproxy=*' that /should/ work
[01:43] <axw> thumper: yep, SGTM
[01:43] <thumper> cherylj: any luck getting it working from the machine not using cloudinit?
[01:44] <natefinch> axw: did my last two comments go through, about the review?
[01:44] <axw> natefinch: looking
[01:45] <natefinch> axw: it was just 15 minutes ago... possibly I was already disconnected and the client didn't tell me
[01:45] <axw> natefinch: last comment I saw from you was from 9.5h ago
[01:45] <axw> ah nope
[01:45] <natefinch> ok :)
[01:47] <natefinch> axw:  I tried moving the set password stuff in the agent code directly but I couldn't find the right time in the startup sequence where it would work.  Did you have an idea of where is appropriate?  I tried just above where I'd put the converter code, at the beginning of the state worker, and pretty near the beginning of all the workers.   I got different errors for each, but unfortunately didn't copy all of them down.
[01:48] <axw> natefinch: lemme see, one minute
[01:54] <axw> natefinch: did you try modifyin OpenAPIState? add an "else" after the "if usedOldPassword", and call entity.SetPassword(info.Password) in it
[01:54] <axw> modifying*
[01:54] <axw> modifyin'
[01:55] <natefinch> axw: nope, but that's a good idea
[01:55] <axw> natefinch: I expect the StateWorker would bounce until that passes, but I think it should keep retrying?
[01:55] <natefinch> axw: it should
[01:55] <mup> Bug #1440940 was opened: xml/marshal.go:10:2: cannot find package "encoding" <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1440940>
[01:56] <axw> natefinch: initially I was thinking stateStarter could not start StateWorker until the API has connected, but I'm not sure if that'll cause problems with API server initialisation when there's only one server ...
[02:01]  * natefinch tries it.
[02:03] <cherylj> thumper: It seems to be a problem using the * wildcard.  If I do --noproxy *, it still tries to go through the proxy.  But if I explicitly list the state server, it bypasses the proxy
[02:03] <thumper> haha
[02:03] <thumper> ha
[02:03] <thumper> hmm
[02:03] <thumper> I know what it is
[02:04] <cherylj> oh?
[02:04] <thumper> the whole command line is being pushed through bash
[02:04] <thumper> * is expanded to all the filenames in the directory
[02:04] <cherylj> I figured it was some substitution like that
[02:04] <thumper> try wrapping it in quotes so bash doesn't expand it
[02:04] <thumper> --noproxy "*"
[02:05] <cherylj> that worked, yay!
[02:05] <thumper> w00t
[02:05] <cherylj> let me try it in the actual code now
[02:05] <thumper> ok
[02:11] <cherylj> thumper: it worked!  huzzah!
[02:11] <thumper> awesome
[02:12] <cherylj> I'm going to turn in for the evening and write the tests for the change in the morning.
[02:12] <thumper> kk
[02:17] <katco> axw: when i do juju storage pool, i don't see "cinder" as an option... what have i done wrong?
[02:17] <katco> axw: juju storage pool list rather
[02:18] <axw> katco: you won't see any pools; there's an implicit pool for each provider, but it's not listed
[02:18] <axw> (perhaps we should change that)
[02:18] <katco> Added charm "local:trusty/hello-world-charm-3" to the environment.
[02:18] <katco> ERROR cannot add service "hello-world-charm": reading pool "cinder": settings not found
[02:18] <katco>  
[02:18] <axw> huh
[02:18] <katco> that was from: juju deploy local:trusty/hello-world-charm --storage="foo=cinder,1MB"
[02:19] <axw> katco: you *bootstrapped* with the feature flag enabled right?
[02:19] <katco> yeah
[02:20] <katco> export JUJU_DEV_FEATURE_FLAGS=storage
[02:20] <katco> and then juju bootstrap --upload-tools
[02:20] <katco> this is on canonistack
[02:21] <katco> i'll try tearing it down and retry just in case
[02:21] <axw> katco: that's weird, the error annotation implies that the error is not a NotFound error, but the cause suggests it is
[02:21] <axw> katco: see storage/poolmanager/poolmanager.go
[02:21] <katco> axw: k
[02:25] <axw> katco: oh, there's a bug in provider/openstack/init.go  -- not sure if it's related
[02:26] <axw> katco: there's an existing call to registry.RegisterEnvironStorageProviders
[02:26] <axw> katco: remove the first one, which is saying that openstack supports no custom storage providers
[02:26] <axw> hmm don't think it's related tho, looks like it'll accumulate
[02:29]  * thumper heads home
[02:30] <katco> axw: lol stale binary >.<
[02:30] <axw> katco: :)
[02:31] <katco> axw: so it's pending... it should eventually show up?
[02:32] <axw> katco: yes, once the instance is created, the storage provisioner should try to create it
[02:33] <axw> katco: we need to add proper status support to storage, it's a little bit difficult to debug what's going on at the moment
[02:35] <katco> axw: agent is started, running hook config-changed
[02:36] <katco> axw: and storage is still pending. hm.
[02:38] <katco> axw: i'm getting some decent errors in debug-log at least
[02:38] <katco> volume "0" not provisioned
[02:38] <katco> getting storage source "cinder": requisite configuration was not set: auth-url not assigned
[02:46] <katco> axw: ah i see... there are some config options i need to set to tell it how to authenticate to canonistack. where do i do that for storage? i.e. how does it get passed into VolumeSource(...)?
[02:46] <axw> katco: hm, why are those pool config attributes? shouldn't they just come from the env config?
[02:46] <axw> I think I glossed over that in my review
[02:47] <axw> katco: sorry, in the VolumeSource method, it should be using environConfig to get the credentials to open a nova/cinder session
[02:47] <katco> i'm getting them from *storage.Config
[02:47] <katco> axw: ah k
[02:48] <axw> katco: see ec2/ebs.go for inspiration if required
[02:48] <katco> i shall seek inspiration :)
[02:49] <katco> axw: fyi the whole provider/* vs. storage/provider/* screwed me up for a long time
[02:49] <katco> axw: i kept wondering if you guys just hadn't checked in the ec2 provider
[02:49] <axw> katco: sorry. the reason it lives in provider/ is because it's closely tied to the environ provider
[02:50] <axw> non IaaS storage providers will go in storage/provider/
[02:50] <katco> axw: totally my fault
[02:50] <katco> axw: i need to turn in, but this looks like we're pretty close. thanks for the help :)
[02:50] <axw> katco: cool :)  no worries, talk to you tomorrow
[02:51] <katco> axw: have a good day!
[02:51] <axw> cheers, good night
[03:00] <natefinch> axw: btw, that suggestion to put it in OpenAPIState works great.
[03:00] <axw> natefinch: awesome
[04:00] <natefinch> axw: added some tests and finished the cleanup & suggestions you had.   Would love to have you re-review.  The tests aren't super thorough, but they're similar to what already existed, so I don't feel too bad (I do still feel bad, but I also need to get this committed).
[04:00] <natefinch> going to bed.  Good night all.
[04:01] <axw> natefinch: yep, just about to hit the button. thanks for the updates
[04:01] <natefinch> axw: thanks for the review.  It's been a big help.
[04:01] <axw> no worries
[04:46] <dimitern> morning all
[07:34] <voidspace> morning all
[07:40] <dooferlad> dimitern: moeninf
[07:40] <dooferlad> dimitern: morning rather
[07:41] <dooferlad> ok, the coffee hasn't hit
[07:41] <dimitern> voidspace, dooferlad, morning!
[07:43] <voidspace> o/
[07:43] <voidspace> coffee is a good idea
[07:48] <TheMue> morning o/
[07:57] <davecheney> o/ europe!
[07:59] <TheMue> davecheney: heya, Mister Vienna
[08:33] <dimitern> dooferlad, I've landed your branches, but we need to clean up a few bits
[08:33] <voidspace> davecheney: what are you doing in Europe - just here early for the sprint or at a conf?
[08:34] <dooferlad> dimitern: yea, I spotted that. Thanks.
[08:36] <dimitern> voidspace, I've tried to land yours but one had conflicts after the first one landed
[08:36] <voidspace> dimitern: yep, fixed and retried
[08:37] <voidspace> dimitern: just now
[08:37] <voidspace> dimitern: creating versions of those fixes for master
[08:37] <dimitern> voidspace, sweet!
[08:37] <voidspace> dimitern: first one applied cleanly and PR created
[08:37] <voidspace> dimitern: second one the patch didn't apply cleanly, looking at now
[08:37] <voidspace> dimitern: thanks for landing the other one
[08:38] <dimitern> voidspace, I'd appreciate if you have a look at bug 1439880 to see if my analysis is correct
[08:38] <mup> Bug #1439880: Container's interfaces are all on private networks instead of host's eth0 network <lxc> <maas-provider> <network> <oil> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1439880>
[08:38] <voidspace> oh god
[08:38] <voidspace> dimitern: ok
[08:38] <dimitern> voidspace, that's most likely the same issue (not found subnets: [])
[08:38] <dimitern> which you fixed already
[08:38] <voidspace> dimitern: ok, I hope so
[08:38] <voidspace> dimitern: looking
[08:40] <dimitern> TheMue, heya, any update on your maas issue?
[08:41] <dimitern> voidspace, LGTM on http://reviews.vapour.ws/r/1391/ btw
[08:42] <voidspace> dimitern: thanks
[08:42] <TheMue> dimitern: I'm an dialog with rvba, lp issue is created. now I at least want to propose my little fix that doesn't stop with an error but returns the default values instead
[08:42] <voidspace> dimitern: yeah, those logs make it seem pretty likely that this is the same issue
[08:42] <voidspace> dimitern: fetching an interface with no subnet and attempting to use that
[08:43] <voidspace> dimitern: we'll see when he tries latest 1.23
[08:43] <dimitern> voidspace, yep, sounds good
[08:43] <dimitern> TheMue, ok, but please follow through with rvba on the issue
[08:44] <TheMue> dimitern: yes, sure, just added a comment
[08:45] <dimitern> voidspace, dooferlad, and BTW I'd appreciate a review on http://reviews.vapour.ws/r/1390/
[08:45] <dooferlad> dimitern: *click*
[08:47] <rvba> TheMue: the screenshot you pasted on bug 1439831 helped a great deal… but do you have access to the full console log?  It's very possible that the cause of the problem could be identified if we had all the log.
[08:47] <mup> Bug #1439831: Missing lshw breaks cloudinit <MAAS:Incomplete> <https://launchpad.net/bugs/1439831>
[08:49] <davecheney> voidspace: sprinting with aram for a week
[08:49] <davecheney> to get some arm64 stuff done before the close of the change window
[08:49] <voidspace> davecheney: cool
[08:49] <TheMue> rvba: I really would like to. sadly I cannot do a cut'n'paste with the vmware console at that time. as far as I know the vmware tools have to be installed at a later time
[08:50] <voidspace> davecheney: Vienna is on my list of "must visit sometime"
[08:50] <dimitern> davecheney, hey, so arm64 support will be released with golang-gc 1.5 ?
[08:50] <voidspace> dimitern: enjoy the sprint
[08:50] <dimitern> I wish :)
[08:50] <TheMue> rvba: but I'll see what I can do
[08:50] <rvba> Thanks.
[08:51] <dimitern> TheMue, have you tried using the vmware CLI tools to capture the console log of the VM ?
[08:51] <dimitern> it should be possible
[08:51] <voidspace> davecheney:: enjoy the sprint
[08:54] <TheMue> dimitern: they can be installed when then the OS is installed
[08:55] <dimitern> TheMue, no, I don't mean the vmware tools that you install on the vm, but the command-line vmware client you can use from the host
[08:56] <TheMue> dimitern: never heard of it, have to search for it
[09:00] <dimitern> TheMue, vmware fusion seems to come with a vmrun command - https://www.vmware.com/pdf/vix162_vmrun_command.pdf which has some interesting features, like running a script inside the guest and copying a file from guest to host - do you have vmrun?
[09:08] <TheMue> dimitern: just took a look, seems to be in the application package and I only have to set it up. sounds like a good way, indeed.
[09:11] <davecheney> voidspace: it's nice here
[09:11] <davecheney> very layed back
[09:11] <davecheney> no forms
[10:21] <davecheney> dimitern: yes, arm64 will ship in go 1.5
[10:21] <davecheney> that's what aram and I are doing this week
[10:21] <dimitern> davecheney, awesome!
[10:22] <dimitern> davecheney, do you know anything about native ppc64 support in gc-go as well?
[10:23] <davecheney> dimitern: same, ppc64 will ship in go 1.5
[10:26] <dimitern> davecheney, \o/ great! I can't wait not to have to care about gccgo/ppc64 bugs :)
[10:30] <davecheney> dimitern: i'm looking forward to your support when I fight for moving everyone up to 1.4 next week
[10:32] <dimitern> davecheney, count on it! :)
[11:08] <dimitern> dooferlad, thanks for the review btw
[11:08] <dimitern> dooferlad, as you progress with the implementation of "space list" you'll need to add a type for Space in params/network (like I did for Subnet)
[11:13] <dimitern> dooferlad, or actually, hold on.. you won't need that - you already have all the info (e.g. list of all spaces - like AllSpaces in cmd/juju/subnet), and the rest should come from a list of params.Subnet for each space's associate subnets
[11:13] <dimitern> dooferlad, most of the rendering code (and tests) could be reused between space list and subnet list, but I'd suggest copying it first and when done
[11:14] <dimitern> dooferlad, ...refactoring it to minimize duplication
[11:23] <dimitern> dooferlad, voidspace, TheMue, last step of the subnets CLI, please take a look http://reviews.vapour.ws/r/1393/ (esp. proof-reading)
[11:27] <lazyPower> o/ Good Morning - there's a member in #juju looking for which ports are required to be open on the juju state server. Does anyone happen to know these ports off the top of their heads?
[11:27] <dimitern> lazyPower, 17070
[11:27] <dimitern> tcp
[11:28] <dimitern> lazyPower, that's the api server, not state server (mongo) which is 37070/tcp, but it's not accessible anyway
[11:28] <lazyPower> ok, so just 17070 and 22 - the rest should be fine in state: closed?
[11:28] <dimitern> lazyPower, most commonly, yeah
[11:29] <lazyPower> right on, cheers dimitern :)
[11:29] <dimitern> lazyPower, no prob :)
[11:56] <jam> axw: katco: I've updated http://reviews.vapour.ws/r/1378/ for now I'm just commenting out the 1 non deterministic test. I'll try to work with william to get it tested again
[12:28] <voidspace> dimitern: if I add issues and then hit "Ship It", does it automaitcally become "Fix it, then ship it"?
[12:29] <voidspace> dimitern: as I can't specifically see an option for that
[12:29] <voidspace> dimitern: anyway, you have a review
[12:31] <jam> wow.... running "worker/uniter" tests causes the test suite to rebuild cmd/jujud/jujud which consumes about 700MB just for the 6l linker...
[12:31] <jam> so much for running the test suite on a 1GB VM
[12:31] <voidspace> dimitern: hmmm... no, it doesn't. Ah well. And I seem to have done it twice :-)
[12:34] <wwitzel3> jam: so it rebuilds it everytime, even if there are no changes?
[12:34] <jam> wwitzel3: I believe the issue probably has to do with JujuConnSuite building tools and "uploading" them to the environment as part of default setup. I don't quite understand why it always rebuilds jujud, but it is probably building everything in a temp dir (I would guess)
[12:36] <wwitzel3> jam: hrmm, wonder if there is a way to avoid that. Rebuilding everything is not an insignificant amount of time and with our test suite already being slow.
[12:37] <jam> wwitzel3: well I only noticed cause i did "go test -c" and then "./uniter.test & ./uniter.test" 10 times and my VM died to swapping :)
[12:37] <wwitzel3> jam: heh
[12:41] <voidspace> dimitern: in the "Juju Container Addressability" doc, is the greyed out section (from the bottom of page 5)
[12:41] <voidspace> dimitern: there for historical reasons only, or do I need to go through that as well?
[12:41] <dimitern> voidspace, it's historical only
[12:41] <voidspace> dimitern: ok
[12:41] <dimitern> voidspace, sorry, I just saw your earlier messages
[12:42] <voidspace> dimitern: I deleted one out of date bullet point and I'm adding an additional one in the "common features" section about the addresser worker
[12:42] <dimitern> voidspace, so AIUI "Fix it, then ship it" turns to "Ship it" once all issues are resolved/dropped
[12:42] <dimitern> automatically
[12:42] <voidspace> dimitern: right, but that wasn't the question
[12:43] <voidspace> dimitern: it was how to post a "Fix it, then ship it" in the first place
[12:43] <voidspace> dimitern: I posted a "Ship It" and it was just a "Ship It"
[12:43] <voidspace> :-)
[12:46] <dimitern> voidspace, ah :) well the "Fix it" part appears when you add any issues and tick the ship it box
[12:47] <voidspace> dimitern: ah!
[12:47] <voidspace> dimitern: thanks
[12:47] <voidspace> I didn't post two "Ship It" reviews - wwitzel3 posted one within the same minute as me...
[12:48] <voidspace> dimitern: hmmm... I have a horrible feeling
[12:48] <voidspace> dimitern: we have the watcher, worker, apiserver ReleaseContainerAddresses method, api client method
[12:49] <voidspace> dimitern: but it doesn't look *to me* like destroying a container calls the ReleaseContainerAddresses method
[12:49] <voidspace> unless I'm missing something
[12:49] <voidspace> I really thought I did that...
[12:50] <voidspace> dimitern: the provisioner should be calling it in StopInstance
[12:50] <dimitern> voidspace, how about adding a few ops in state around machine destruction?
[12:51] <voidspace> dimitern: so when the machine is destroyed in state release the addresses
[12:51] <voidspace> dimitern: then we don't need the api
[12:52] <voidspace> and the logic is simpler
[12:53] <voidspace> we have the machine ID, just find all IP addresses with that machine ID and mark Life as dead
[12:53] <voidspace> no need for the unit agent to do it, so no need to check permissions
[12:54] <voidspace> dimitern: I'll create an issue and a kanban card *sigh*
[12:57] <dimitern> voidspace, thanks
[12:57] <dimitern> voidspace, yes, that sounds like a better approach - the provisioner API RCA() can still stay (for now at least)
[12:57] <voidspace> dimitern: heh, you just unassigned me from a three year old bug
[12:58] <dimitern> voidspace, I think it's safer to do it in state though
[12:58] <voidspace> dimitern: yep
[12:58] <dimitern> voidspace, are you still working on it? :)
[12:58] <voidspace> dimitern: I might have got round to it...
[12:59] <dimitern> voidspace, well, in that case feel free to reassign yourself then :)
[13:00] <voidspace> dimitern: I think I'll skip it...
[13:05] <sinzui> mgz, dimitern Can either of you review http://reviews.vapour.ws/r/1394/
[13:10] <mgz> sinzui: on it
[13:10] <mgz> sinzui: lgtm
[13:11] <sinzui> thank you mgz
[13:12] <voidspace> aargh, spotify killed unity again
[13:12] <voidspace> mouse no longer works, events blocked
[13:12] <voidspace> I can alt-tab and type
[13:12] <voidspace> but can't use a browser very well
[13:12] <voidspace> will reboot and go on lunch, create tickets (and work on them) after that
[13:25] <jam> sinzui: abentley: i see "inc-1.23-beta4" in the pipeline, and I'm trying to land the "remove leader-election flag for 1.23" as well.
[13:25] <jam> It bounced once due to AddRemoveSet
[13:26] <jam> but it should land
[13:27] <sinzui> jam, yes, 1.23-beta3 was sent to the builders. we will release a 1.23-beta4 later this week or next if need be
[13:28] <sinzui> dimitern, bug 1427814 should be High, or we should remove it from the milestone. We don't commit Medium bugs to deadlines.
[13:28] <mup> Bug #1427814: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged by themue> <juju-core 1.23:Triaged by themue> <https://launchpad.net/bugs/1427814>
[13:28] <dimitern> sinzui, ok, I'll retriage it as high then
[13:29] <sinzui> thank you dimitern
[13:44] <mup> Bug #1427508 changed: cmd/jujud/agent: test failure <intermittent-failure> <tech-debt> <test-failure> <juju-core:Fix Released> <juju-core 1.23:Fix Released> <https://launchpad.net/bugs/1427508>
[13:44] <mup> Bug #1438168 changed: juju 1.23 doesn't release IP addresses for containers <juju-core:Fix Released by mfoord> <https://launchpad.net/bugs/1438168>
[13:44] <mup> Bug #1438683 changed: Containers stuck allocating, interface not up <add-machine> <cloud-installer> <landscape> <maas-provider> <network> <juju-core:Fix Released by mfoord> <https://launchpad.net/bugs/1438683>
[13:44] <mup> Bug #1438820 changed: IP address life field upgrade step and addresser worker don't play well together <juju-core:Fix Released by mfoord> <https://launchpad.net/bugs/1438820>
[13:58] <natefinch> ericsnow, wwitzel3: note the moved standup
[13:58] <natefinch> (in an hour)
[13:59] <ericsnow> natefinch: k
[13:59] <perrito666> ericsnow: are you not in pycon?
[13:59]  * perrito666 looks at the calendar and acuses it of lying
[13:59] <ericsnow> perrito666: leaving for the airport in 4 hours
[14:00] <perrito666> ahh :D makes sense
[14:00] <perrito666> my calendar, given my tz, has shown me things in the wrong day before
[14:00] <ericsnow> perrito666: the calendar's right, it just doesn't show today as partial :)
[14:02] <wwitzel3> ahh, I see that now
[14:02] <wwitzel3> hangout is the best max fan speed tool for Linux, even steam doesn't get it cranked like hangout
[14:03] <perrito666> wwitzel3: get hardware accel for it
[14:34] <ericsnow> natefinch: one-on-one?
[14:34] <natefinch> ericsnow: I think we can skip it unless there's something you need
[14:34] <ericsnow> natefinch: nah
[14:34] <natefinch> ericsnow: cool.  See you in Nuremberg.  Have fun at pycon.
[14:35] <ericsnow> dimitern: thanks for hopping onto that vmware networking thread
[14:35] <voidspace> natefinch: can you remove me from the list of attendees to moonstone standups please
[14:35] <voidspace> natefinch: I don't think I can do it...
[14:35] <ericsnow> dimitern: I think we have a good enough plan going forward, but I want to be sure I'm understanding the juju networking model correctly
[14:36] <voidspace> natefinch: I keep getting updated invitations to your standups :-)
[14:36] <ericsnow> voidspace: were we that bad? <wink>
[14:36] <voidspace> ericsnow: yep <wink>
[14:37] <wwitzel3> lol
[14:37] <voidspace> ericsnow: you at pycon yet?
[14:37] <voidspace> :-)
[14:37] <ericsnow> voidspace: flying out in a few hours
[14:37] <voidspace> ericsnow: have fun, I'll miss everyone :-(
[14:37] <ericsnow> voidspace: way only just told that the posters can be 4x8 (feet)
[14:38] <wwitzel3> lol
[14:38] <voidspace> hah
[14:38] <ericsnow> voidspace: but it does allow me to fit more stuff on there :)
[14:39] <voidspace> good
[14:39] <wwitzel3> less is more for posters
[14:39] <dimitern> ericsnow, sure, I'll dig into the discussion so far and respond (but most likely tomorrow)
[14:39] <ericsnow> wwitzel3: pshaw
[14:39] <ericsnow> dimitern: np, thanks!
[14:39] <wwitzel3> poeple want to be drawn in by the poster, a core concept on the post that is easy to follow will generate interest and questions
[14:40] <voidspace> just have a picture of a cloud
[14:40] <wwitzel3> a big diagram full of stuff = empty poster session
[14:40] <ericsnow> wwitzel3, voidspace: apparently there are also accommodations for a laptop, so I may demo some stuff too
[14:40] <ericsnow> wwitzel3: true
[14:40] <ericsnow> voidspace: :)
[14:40] <voidspace> ericsnow: I would have a predeployed local environment with gui
[14:40] <wwitzel3> yeah, was just going to say, use the GUI :)
[14:41] <ericsnow> voidspace: more homework? :)
[14:41] <voidspace> heh, it's easy...
[14:41] <ericsnow> voidspace: I'm probably going to set up openstack
[14:41] <voidspace> wowzer :-)
[14:42] <voidspace> so, deploy openstack with juju and then deploy to that openstack with juju
[14:42] <ericsnow> voidspace: :)
[14:42] <ericsnow> voidspace: TBH, I wasn't planning on using a laptop, but it's so tempting
[14:43] <voidspace> being able to show a deployed environment through the gui is nice
[14:43] <voidspace> showing the relationships
[14:43] <ericsnow> voidspace: yep
[14:44] <voidspace> gmail has decided, fairly reasonably in my opinion..., that all those blessed/cursed emails are spam...
[14:44] <perrito666> voidspace: I added a filter
[14:44] <voidspace> perrito666: I have a thunderbird filter - I use imap
[14:44] <ericsnow> voidspace: the demo openstack page that lazyPower posted inspired me
[14:45] <perrito666> voidspace: saying that these where not spam :p because I assumed they where going to be taken as such
[14:45]  * lazyPower perks up
[14:45] <voidspace> perrito666: but gmail is moving them to spam before I get to them
[14:45] <lazyPower> o/
[14:45] <perrito666> voidspace: you can nevertheless add a filter in gmail
[14:45] <voidspace> perrito666: heh
[14:45] <voidspace> perrito666: I could do...
[14:45] <perrito666> voidspace: its no more than 5 clicks
[14:45] <voidspace> perrito666: I wish gmail would leave my damn email alone and let me handle it thank you very much
[14:46] <perrito666> voidspace: well, I havent looked in my canonical acct, but in my regular acct I get a lot of spam so I am fairly happy with gmails filter
[14:46] <perrito666> but, I use gmail as a client
[14:46] <wwitzel3> voidspace: you can disable the spam filtering completely
[14:46] <voidspace> yeah, I don't like web clients
[14:46] <perrito666> voidspace: I like consistent clients :p so with that I get the same client on my phone, my tablet and my laptop
[14:47] <voidspace> it's sucky - hey, but at least it's sucky everywhere!
[14:47] <perrito666> voidspace: and I pretty much like the ui so I would really use a desktop client if it provided the same interface
[14:47] <voidspace> right
[14:47] <voidspace> I prefer the thunderbird ui
[14:47] <perrito666> the idea of labels instead of folders is the killer feature for me
[14:47] <voidspace> that's the killer un-feature for me!
[14:47] <voidspace> I like folders dammit
[14:50] <ericsnow> I don't mind the labels, but the filters drive me nuts
[14:50] <ericsnow> you can't prioritize them
[14:50] <ericsnow> (they *all* get run)
[14:51] <wwitzel3> voidspace: if you create a filter for Has Words: is:spam and check never mark as spam, you essentially disable the spam filtering
[14:51] <ericsnow> wwitzel3: nice :)
[14:51] <wwitzel3> voidspace: I did that for my Canonical email after I missed a few that were sent to spam.
[14:51] <perrito666> voidspace: I am a person with difficulties making choices so If I can put an email in many folders it solves my problem :p
[14:55] <dimitern> TheMue, hey, any progress on the maas issue? Did you manage to use vmrun successfully?
[14:56] <TheMue> dimitern: hehe, just wanted to ping you. vmrun does not help, it is only a CLI tool doing the same as the UI. when wanting to get into the running machine you need a user/password.
[14:57] <natefinch> voidspace: ha, sorry, I can fix it.
[14:57] <TheMue> dimitern: but I'm currently setting up a serial debugging console hoping to grabbing the output there
[14:57] <TheMue> dimitern: found some docs at vmware and in forums on how to set it up
[14:57] <dimitern> TheMue, that's an option yeah
[14:58] <TheMue> dimitern: I'm not aware what I'll see there, but I've got almost no other idea
[14:58] <TheMue> dimitern: one option I found too is simply do a screen recording, creating a kind of console output film
[14:58] <TheMue> dimitern: :)
[14:58] <voidspace> wwitzel3: hah, nice - thanks
[14:59] <TheMue> dimitern: if only this initial ubuntu user would have a password to login *sigh*
[15:00]  * TheMue is frustrated
[15:00] <voidspace> natefinch: thanks :-)
[15:02] <dimitern> TheMue, if only cloud-init did it's job :)
[15:02] <perrito666> natefinch: standup?
[15:02] <TheMue> dimitern: exactly, the a simple ssh would be no problem
[15:04] <natefinch> sinzui: what's up with https://bugs.launchpad.net/juju-core/+bug/1440940  ??  It looks like it's a build environment problem, since it's not able to find the stdlib's encoding package.
[15:04] <mup> Bug #1440940: xml/marshal.go:10:2: cannot find package "encoding" <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1440940>
[15:05] <sinzui> natefinch, I hope a developer can explain what is up so that I can fix it. We haven't changed packaging on that machine in months
[15:06] <sinzui> natefinch, you think encoding is provided by a specific ubuntu package?
[15:06] <natefinch> sinzui: encoding is a go package that is part of the go standard library
[15:07] <voidspace> yeah, that's odd
[15:08] <sinzui> natefinch, stilson-07 only had kernels in /usr/src
[15:09] <natefinch> sinzui: seems like goroot is set incorrectly there
[15:09] <natefinch> sinzui: $GOROOT seems to be set to /usr/
[15:10] <sinzui> natefinch, what should goroot be on a machine that uses gccgo?
[15:13] <sinzui> mgz can you and natefinch sort out what stilson-07 needs (that I presume stilson-08 has) to allow us to run unit tests? I am at a critical moment in a release that affects production streams
[15:13] <natefinch> sinzui: no problem
[15:13] <mgz> sure
[15:14] <natefinch> sinzui, mgz:  goroot doesn't need to be set, the go tool figures it out on its own for the most part.
[15:14] <mgz> natefinch: so, you say I unset that and it compiles?
[15:15] <sinzui> mgz, since 1.23 and 1.22 works, I think something is different about the package or the Makefile
[15:15] <natefinch> mgz: I am 100% sure there's no possible way that anything else could possibly be wrong
[15:15] <mup> Bug #1441206 was opened: Container destruction doesn't mark IP addresses as Dead <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1441206>
[15:15]  * natefinch hopes they get the sarcasm'
[15:15] <sinzui> mgz, tarball, not package. stilson-08 takes the same tarball and made packages.
[15:15] <natefinch> mgz: unsetting it should work, but I can't be sure there's nothing else wrong
[15:17] <mgz> natefinch: paste.ubuntu.com/10763144
[15:18] <natefinch> mgz: what does `go env` return ?
[15:18] <mgz> the reason trunk is broken and 1.23 is not is that the xml package from the stdlib was forked as a dep
[15:18] <mgz> and that's what's not compiling
[15:18] <mgz> sinzui: ^that change is on trunk only
[15:19] <mgz> natefinch: GOROOT=/usr
[15:19] <natefinch> mgz: it sounds like the installation of go is messed up
[15:20] <mgz> I can purge it and reinstall
[15:21] <mup> Bug #1441206 changed: Container destruction doesn't mark IP addresses as Dead <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1441206>
[15:22] <mgz> natefinch: stilson-08 also says /usr for GOROOT through go env
[15:22] <natefinch> mgz: how did you guys get Go installed on those machines?
[15:24] <mgz> natefinch: apt-get install
[15:26] <natefinch> mgz: oh, yeah, I guess that's actually the correct goroot...  I had forgotten how it works when you use apt-get
[15:27] <rogpeppe1> natefinch: hiya
[15:28] <natefinch> rogpeppe1: howdy
[15:28] <rogpeppe1> natefinch: just wondering if you know how to quote an arbitrary argument passed to cmd.exe; we're trying to write a platform-general "open link in web browser" package
[15:29] <natefinch> mgz: still, that means there should be a /usr/src/pkg/encoding/encoding.go
[15:29] <rogpeppe1> natefinch: and i don't trust the implementation https://github.com/toqueteos/webbrowser/blob/master/webbrowser.go
[15:29] <mgz> rogpeppe1: just look at the python module and do that?
[15:29] <rogpeppe1> mgz: link?
[15:29] <alexisb> dimitern, ping
[15:29] <dimitern> alexisb, pong
[15:30] <mgz> rogpeppe1: there's a function in subprocess.py that does quoting, and webbrowser does what you're doing
[15:30] <rogpeppe1> mgz: it's not just normal quoting unfortunately
[15:30] <rogpeppe1> mgz: it's quoting past cmd.exe, which is somewhat harder, i think
[15:30] <mgz> rogpeppe1: `vi /usr/lib/python2.7/subprocess.py`
[15:31]  * perrito666 suggests rogpeppe1 asks gsamfira 
[15:31] <rogpeppe1> mgz: not really keen on that implementation
[15:31] <natefinch> mgz: hmm... except that installing it locally doesn't do that either....
[15:31] <rogpeppe1> mgz: it doesn't seem to respect user web browser preferences, although i may not have seen that bit
[15:32] <mgz> rogpeppe1: /list2cmdline
[15:32] <natefinch> mgz: ahh... when I install go from apt, it gives me goroot = /usr/lib/go
[15:32] <mgz> rogpeppe1: it looks at the BROWSER envvar on nix, not sure if it looks up the registry setting or whatever on windows
[15:33] <mup> Bug #1441206 was opened: Container destruction doesn't mark IP addresses as Dead <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1441206>
[15:33] <rogpeppe1> mgz: isn't list2cmdline just for executing a command directly?
[15:33] <mgz> I also don't like webbrowser much, but it'll cover a bunch of cases you don't think if otherwise
[15:33] <rogpeppe1> mgz: whereas what we are thinking of doing is running cmd /c start $url
[15:34] <rogpeppe1> mgz: and in that case there are a bunch of cmd.exe metachars that would need quoting (& being the most obvious)
[15:34] <mgz> rogpeppe1: see also `if shell:` in _execute_child
[15:34] <rogpeppe1> mgz: link?
[15:34] <mgz> same file
[15:34] <mgz> further down
[15:35] <ericsnow> rogpeppe1: did you see the shell package in the utils repo?
[15:35] <ericsnow> rogpeppe1: it has code for shquoting
[15:35] <rogpeppe1> mgz: i don't see it inhttps://hg.python.org/cpython/file/2.7/Lib/webbrowser.py
[15:35] <rogpeppe1> ericsnow: ah, in windows too, cool
[15:36] <ericsnow> rogpeppe1: both powershell and cmd.exe, I believe
[15:36] <ericsnow> rogpeppe1: powershell is easier, BTW
[15:36] <natefinch> rogpeppe1:  wow, I was totally confused about what you meant by quoting
[15:37] <natefinch> rogpeppe1: would just putting quotes around it not work?
[15:37] <rogpeppe1> natefinch: probably not
[15:38] <rogpeppe1> natefinch: because they'll get quoted by the Go syscall quoting mechanism, i think
[15:38] <natefinch> rogpeppe1: Oh I see
[15:39] <mgz> rogpeppe1: you were asking about the subprocess function, that file
[15:40] <rogpeppe1> i think this (from winCmdEscapeMeta) has what i need: 	const meta = `()%!^"<>&|`
[15:40] <natefinch> rogpeppe1: http://stackoverflow.com/questions/1327431/how-do-i-escape-ampersands-in-batch-files
[15:40] <rogpeppe1> natefinch: yeah, i know about ampersands
[15:41] <rogpeppe1> natefinch: it was all the other stuff that you can find in urls that i'm concerned about
[15:41] <natefinch> rogpeppe1: right ok
[15:45] <natefinch> sinzui, mgz: can we mark #1440940 as not blocking trunk?  It's not a code issue that dev can fix.
[15:45] <mup> Bug #1440940: xml/marshal.go:10:2: cannot find package "encoding" <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1440940>
[15:45] <natefinch> of that I'm 100% sure
[15:48] <mgz> natefinch: have you successfully built on gccgo locally with trunk?
[15:48] <natefinch> mgz: not recently, but I can give it a go
[15:48] <natefinch> (heh)
[15:51] <mgz> natefinch: I think unblocking trunk when know one knows if t
[15:52] <mgz> it actually builds or not on one of our supported platforms, is probably not a good idea
[15:52] <natefinch> mgz: I actually had thought we decided that errors with gccgo builds weren't going to block trunk, but maybe I misunderstood.   I am compiling with gccgo now, btw.
[15:54] <sinzui> natefinch, I think the issue is that Ubuntu require this to work and we need to prove it is a compiler issue that they manage, not a code issue in Juju
[15:59] <natefinch> sinzui: well, it's certainly a compiler issue.  It can't find a package from the standard library.   FWIW, I just finished a build of trunk with gccgo with no issues
[16:00] <sinzui> mgz: This atrociously long log shows gccgo did compile the ppc64el package on stilson-08
[16:00] <natefinch> sinzui: my suggestion is to remove and reinstall golang on that machine... maybe the installation got corrupted somehow
[16:01] <sinzui> natefinch, but isn't this about xml being forked. 1.22 and 1.23 build fine
[16:02] <natefinch> sinzui: the error from the compiler clearly says that it can't find the encoding package from the standard library. it's not about the forked xml package... that's just the leaf-most package that happens to import encoding, and therefore shows the error.
[16:03] <natefinch> sinzui: those other branches build fine on the same machine?
[16:04] <sinzui> natefinch, yes
[16:05] <mgz> natefinch: it really is about the change that introduced that, it's when it started breaking
[16:06] <natefinch> sinzui: hmm.... so before, we didn't import encoding directly in our code at all, only indirectly through importing xml.  Now we do it directly.  I wonder if that somehow is triggering this issue.
[16:06] <sinzui> neither stillson has golang* package installed
[16:07] <natefinch> sinzui: where is it getting the go tools from, then?
[16:07] <sinzui> mgz, is xml defined in dependencies.tsv?
[16:07] <sinzui> natefinch, I think they get it from gccgo
[16:09] <mgz> sinzui: our forked version is, for trunk
[16:09] <sinzui> mgz, yes, which is why I think Ubuntu can say the issue is in Juju's code
[16:10] <natefinch> sinzui: the problem is that the standard library package "encoding" isn't there.  That's not a bug in juju's code.
[16:11] <mgz> yeah, I wanted to grab dave or someone to work out what about the root package import is unhappy on gccgo
[16:11] <mgz> natefinch: but all the encoding/blah imports are fine
[16:14] <sinzui> mgz, stilson-08 will work because it is packaging...debian deps will ensure the fakeroot will get the source.
[16:18] <natefinch> mgz, sinzui: can one of you try copying this program to a file on that machine and doing gccgo run <thatfile>?  http://play.golang.org/p/6b1LdO_13i
[16:19] <sinzui> mgz stilson-07 doesn't have golang-go src and it hasn't needed it because I think the tarball gets all the golang go pakages needed. GOROOT is irrelevant for the tarball because the static link rules require we provide everything that ubuntu needs to audit
[16:19] <sinzui> mgz, so I wonder if xml is being removed when the tarball is created because it isn't stated to be required
[16:21] <mgz> natefinch: yeah, that does not compile
[16:21] <mgz> sinzui: we shouln't be tarring up stdlib bits
[16:22] <mgz> sinzui: so, I'm pretty sure the tarball is just fine, it has the forked xml
[16:22] <sinzui> mgz, then lets install std libs on stilson-07
[16:22] <sinzui> mgz, the are not there and I don't think they every were
[16:23] <mgz> sinzui: okay, I think there is an actual bug here, but I'm fine just sticking golang on if that's enough
[16:35] <natefinch> mgz, sinzui:  certainly if that 12 line program doesn't compile, it's not a juju issue.   Something is fubared with the environment.  It seems like installing the go compiler on the machine on which you intend to compile go code should be uncontroversial ;)
[16:36] <natefinch> I have to run for a couple hours to do tax stuff.
[16:36] <sinzui> natefinch, mgz, apt tells me that golang-src isn't available for ppc64el
[16:36] <natefinch> lol
[16:36] <natefinch> sinzui: it's pretty easy to build from source
[16:36] <sinzui> natefinch, I really don't know what provided xml or encodings in the past
[16:36]  * natefinch shrugs
[16:37] <natefinch> I gotta run, sorry.    http://golang.org/doc/install/source
[16:37] <sinzui> natefinch, the machine is setup using the juju Makefile so we don't create custom setups
[18:27] <mup> Bug #1423936 changed: Juju backup fails when journal files are present <backup-restore> <cts> <juju-core:Fix Released by niedbalski> <juju-core 1.22:Fix Released by niedbalski> <juju-core 1.23:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1423936>
[18:27] <mup> Bug #1436191 changed: gce: bootstrap instance has no network rule for API <firewall> <gce-provider> <juju-core:Fix Released by dimitern> <juju-core 1.23:Fix Released by dimitern> <https://launchpad.net/bugs/1436191>
[18:27] <mup> Bug #1436390 changed: GCE provider config should support extracting auth info from JSON file <gce-provider> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.23:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1436390>
[18:27] <mup> Bug #1436397 changed: map-order sensitive test in md/juju/storage needs to be fixed <map-order> <juju-core:Fix Released by anastasia-macmood> <https://launchpad.net/bugs/1436397>
[18:27] <mup> Bug #1436415 changed: vivid local template container "juju-vivid-lxc-template" did not stop' <ci> <lxc> <tech-debt> <vivid> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.23:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1436415>
[18:27] <mup> Bug #1436655 changed: gce provider should stop using deprecated zone europe-west1-a <gce-provider> <juju-core:Fix Released by wwitzel3> <juju-core 1.23:Fix Released by wwitzel3> <https://launchpad.net/bugs/1436655>
[18:27] <mup> Bug #1436988 changed: juju backup/restore is upstart-specific <backup-restore> <systemd> <vivid> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.23:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1436988>
[18:27] <mup> Bug #1437038 changed: 1.23b2 fails to get IP from MAAS for containers, falls back to lxcbr0 <addressability> <maas-provider> <network> <juju-core:Fix Released by mfoord> <juju-core 1.23:Fix Released by mfoord> <https://launchpad.net/bugs/1437038>
[18:27] <mup> Bug #1437220 changed: gce provider often can't find its own instances <gce-provider> <observability> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.23:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1437220>
[18:27] <mup> Bug #1437296 changed: apt-http-proxy being reset to bridge address <local-provider> <proxy> <juju-core:Fix Released by anastasia-macmood> <juju-core 1.22:Fix Released by anastasia-macmood> <juju-core 1.23:Fix Released by anastasia-macmood> <https://launchpad.net/bugs/1437296>
[18:27] <mup> Bug #1437366 changed: MAX_ARGS is reached when calling relation-set <charm> <landscape> <relations> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.23:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1437366>
[18:27] <mup> Bug #1438748 changed: Use of /tmp/discover_init_system.sh is a security vulnerability. <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.23:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1438748>
[18:27] <mup> Bug #1439398 changed: GCE low-level RemoveInstances fails if firewalls are not found <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.23:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1439398>
[18:27] <mup> Bug #1439761 changed: AWS V4 signing does not work <ec2-provider> <juju-core:Fix Released by cox-katherine-e> <juju-core 1.23:Fix Released by cox-katherine-e> <https://launchpad.net/bugs/1439761>
[18:28] <voidspace> right, I'm off
[18:28] <voidspace> g'night all
[18:28] <voidspace> EOD
[18:46] <mup> Bug #1441302 was opened: Vivid unit tests are not reliable enough <test-failure> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1441302>
[20:01] <mup> Bug #1441319 was opened: failed to retrieve the template to clone: template container juju-trusty-lxc-template did not stop <lxc> <oil> <juju-core:Triaged> <https://launchpad.net/bugs/1441319>
[20:42] <natefinch> sinzui: anything I can do to help with that gccgo problem?
[20:43] <natefinch> wwitzel3: you going to be on the release call tonight?
[20:44] <sinzui> natefinch, I update the bug with what I learned. gccgo doesn't use goroot. The libgo5 package is still installed and the encoding package is there
[20:44] <sinzui> natefinch, I an currently attempting a reinstall because I I cannot think of anything wlse to do
[20:44] <davecheney> which bug is this ?
[20:45] <mgz> ah, dave is who I wanted
[20:45] <natefinch> davecheney: https://bugs.launchpad.net/juju-core/+bug/1440940
[20:45] <mup> Bug #1440940: xml/marshal.go:10:2: cannot find package "encoding" <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1440940>
[20:45] <davecheney> tada, i'm here in your timezone
[20:45] <davecheney> natefinch: that bug is because someone wrote code with Go 1.4 features
[20:45] <davecheney> (i think)
[20:45] <davecheney> checking
[20:45]  * perrito666 managed to organize a go meetup in his city tonight, the whole go community is coming... al 8 of them
[20:46] <mgz> davecheney: so, it started happening because we copied the encoding/xml package into our namespace
[20:47] <davecheney> why they heck did you do that ?
[20:47] <davecheney> sounds like you solved a big problem by lighting a massive house fire
[20:47] <davecheney> s/big/small
[20:47] <mgz> "to make marshalling of namespaced attributes work correctly"
[20:47] <davecheney> in short, we won't get that fix til next year
[20:47] <davecheney> sorry
[20:48] <mgz> anyway, for whatever reason, the import of just "encoding" from that package doesn't work on a vanilla install of gccgo on trusty, for reasons I don't understand
[20:50] <davecheney> mgz: which commit was this ?
[20:51] <mgz> butI believe it came in with the new charmstore api
[20:52] <natefinch> davecheney: note that a simple gccgo run of this code fails on that machine (though it works fine on my machine): http://play.golang.org/p/6b1LdO_13i
[20:52] <mgz> davecheney: note, a trivial script that imports encoding also fails
[20:52] <natefinch> heh
[20:52] <davecheney> maybe that package doesn't exist in gccgo
[20:52] <mgz> (unless you have golang installed as well I believe)
[20:53] <davecheney> mgz: if installing go as well as gccgo fixes the problem
[20:53] <davecheney> that is extremely super bafd
[20:53] <davecheney> that is extremely super bad
[20:53] <mgz> I can confirm that on a fresh amd64 vm if that would be helpful
[20:53] <davecheney> ok
[20:54] <davecheney> in terms of getting a fix
[20:54] <davecheney> you have to roll that back if you want to be able to release this week
[20:54] <davecheney> getting a fix into gccgo-4.9 is impossible on that timeframe
[20:54] <thumper> o/
[20:54] <mgz> the other option maybe is... also forking the root encoding package into juju/
[20:54] <katco> o/ thumper
[20:55] <davecheney> mgz: this sounds like taking a bad situation and making it worse
[20:55] <mgz> of course :)
[20:57] <mgz> or copying in the TextMarshalelr class to the forked package, 's all it uses
[21:01] <wwitzel3> natefinch: yep
[21:06] <natefinch> wwitzel3: cool, thank you.  My main concern is this CI bug (https://bugs.launchpad.net/juju-core/+bug/1440940) that is blocking me from getting my HA stuff in.   My position is that this is just an environmental problem, not a bug in our code, since they can reproduce the problem with trivial code that doesn't even use juju.
[21:06] <mup> Bug #1440940: xml/marshal.go:10:2: cannot find package "encoding" <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1440940>
[21:06] <natefinch> I gotta run, sorry guys.  Good luck.
[21:19] <davecheney> i thought we had a standing rule to revert any change which was blocking CI
[21:20] <mgz> davecheney: yeah, so that hasn't happened in practice, and this was a complex one anyway
[21:20] <mgz> the forking of the package happened a while before it was added as a dep to juju-core,
[21:22] <mgz> and the fact we reuse ppc machines for packaging meant this wasn't caught immediately,
[21:22] <mgz> and everyone whines if we actually block trunk on ppc issues
[21:22] <mgz> so we don't do that any more, but we still need to actually *release* a working juju on ppc
[21:23] <davecheney> this sounds like double speak
[21:23] <davecheney> ppc either blocks releases or it doesn't
[21:23] <davecheney> and from what i'm hearing, it doesn't
[23:10] <katco> axw: do you mind if i ping you later for the standup?
[23:10] <axw> katco: no problem, how much later? I may need to go back downstairs
[23:10] <katco> axw: hour or so from now?
[23:10] <axw> katco: okey dokey
[23:11] <axw> school holidays atm, so I'm easy
[23:57] <katco> axw: is now a good time?