[00:04] <anastasiamac_> wallyworld: r u getting my msgs?...
[00:05] <wallyworld> yes, but in the midle of something
[00:05] <wallyworld> be with you in a sec
[00:06] <anastasiamac_> wallyworld: k :D
[00:53] <katco> anastasiamac_: 0/ how are you
[00:53] <anastasiamac_> katco: o/ m good :D
[00:53] <anastasiamac_> katco: u?
[00:53] <katco> anastasiamac_: doing good!
[00:54] <davecheney> thumper: did my performance review, with literally hours to spare
[00:54] <davecheney> a new record
[00:55] <thumper> davecheney: thanks
[00:55] <thumper> davecheney: when are you off?
[00:55] <davecheney> flight leaves at three
[00:55] <davecheney> i need to get my ass in a cab
[00:55] <thumper> :)
[00:55] <thumper> have a good trip
[00:56] <davecheney> will do
[01:51] <beisner> sinzui & co. -  fi scenario does indeed succeed with 1.20.x - bug updated https://bugs.launchpad.net/juju-core/+bug/1420049
[01:51] <mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1420049>
[01:51] <sinzui> beisner, thank you very much.
[01:51] <beisner> s/fi/fyi/
[01:52] <beisner> sinzui, happy to test it.  holler if you need me to throw anything else against that hardware.
[01:53] <sinzui> wallyworld, bug 1420049 is confirmed to be a regression from 1.20.x
[01:53] <mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1420049>
[01:58] <sinzui> wallyworld, bug 1407699 appears to be back. precise and aws and lxc are failing in CI for branch 1.22
[01:58] <mup> Bug #1407699: Precise services cannot be deployed <ci> <deploy> <precise> <regression> <juju-core:Fix Released by wallyworld> <cloud-init (Ubuntu):New> <https://launchpad.net/bugs/1407699>
[01:59] <waigani> wallyworld: http://reviews.vapour.ws/r/928/ - one issue unresolved, I've replied with a possible solution, see what you think
[02:09] <anastasiamac_> thumper: howdy? r u looking at bug 1421237?....
[02:09] <mup> Bug #1421237: DEBUG messages show when only INFO was asked for <ci> <regression> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1421237>
[02:09] <anastasiamac_> thumper: it currently blocks CI :D
[02:10] <thumper> anastasiamac_: I'm busy arguing about it - it isn't us
[02:10] <anastasiamac_> thumper: \o/
[02:13] <thumper> I've just commented again
[02:13] <thumper> and moved it back to incomplete
[02:13] <thumper> I'm guessing the problem is environmental
[02:21] <anastasiamac_> thumper: :D
[02:21] <thumper> wallyworld: you around?
[02:22] <thumper> wallyworld: I'd like you to join waigani and me for a chat about destroy environment behaviour
[02:22]  * thumper looks at the time and guesses wallyworld is having lunch
[02:23] <thumper> waigani: probably best to wait for wallyworld
[02:23] <thumper> so I'm not repeating myself
[02:23] <thumper> we are going to need clear docs around this too :-)
[02:24] <waigani> thumper: ah yep okay
[02:25] <rick_h_> thumper: how goes?
[02:25] <thumper> rick_h_: good
[02:25] <thumper> rick_h_: I'm wanting more feedback on my spec BTW
[02:25] <rick_h_> thumper: k, will see what I can do
[02:25] <thumper> I'm going to chase up john too
[02:25] <rick_h_> thumper: good plan
[02:25] <thumper> rick_h_: I may take urulama off the approval list
[02:25] <rick_h_> thumper: k
[02:26] <thumper> as I've removed many references to other things out of the scope of the spec
[02:26] <thumper> rick_h_: and I'm wanting to get moving on this ASAP
[02:26] <rick_h_> thumper: understand
[02:27]  * thumper is considering a flag called --dont-look
[02:27] <thumper> or perhaps --jfdi
[02:27] <thumper> nah
[02:27] <rick_h_> what part needs jfdi'ing?
[02:28] <thumper> perhaps it should be --i-know-there-are-no-other-environments
[02:28] <thumper> juju destroy-environment --force
[02:28] <thumper> when there are possibly multiple environments
[02:28] <rick_h_> ugh
[02:28] <thumper> it'll leave other environments running
[02:28] <thumper> but in a deadish state
[02:28] <rick_h_> gets back to new commands for 'server' vs environment
[02:29] <rick_h_> this 'special' environment thing is going to kill us
[02:29] <thumper> do you think it should be 'juju server destroy' ?
[02:29] <rick_h_> juju destroy-environment --force ec2 does just that, juju destroy-server is what you need to kill a JES
[02:29] <rick_h_> yep, no way to do it on accident
[02:29] <thumper> but...
[02:29] <thumper> there is no --force
[02:29] <thumper> for a non-server environment
[02:30] <thumper> we do that anyway
[02:30] <thumper> provider, plz kill all these machines
[02:30] <rick_h_> ok, so what?
[02:30] <rick_h_> so there's not a flag --force on the new command for a JES
[02:30] <thumper> so 'juju server login' ?
[02:30] <rick_h_> big deal
[02:30] <rick_h_> +1 from me
[02:30] <thumper> juju server list?
[02:30] <rick_h_> make it less magical to users
[02:30] <thumper> what does that mean?
[02:30] <rick_h_> list servers that I have cached local info about
[02:31] <rick_h_> e.g. list the servers I've logged into
[02:31] <thumper> not list me the environments on the current server?
[02:31] <rick_h_> nope, that's juju login some-server
[02:31] <rick_h_> juju environment list
[02:31] <rick_h_> and I don't expect to see the JES in that list
[02:31] <thumper> hmm...
[02:31] <rick_h_> basically don't expose the implementation detail to user, make it a completely safe split
[02:32] <rick_h_> in my opinion and all that
[02:32] <rick_h_> otherwise there's too many 'oops' and 'doh' cases to think about
[02:32] <thumper> now we are breaking history
[02:32] <rick_h_> what history? JES is new :)
[02:32] <thumper> because destroy-environment now isn't how you stop a local environment
[02:32] <rick_h_> it's a new feature with new commands and ...
[02:32] <thumper> bootstrap still starts and environment
[02:32] <rick_h_> how does one stop a local environment then?
[02:33] <rick_h_> bootstrap starts a JES
[02:33] <rick_h_> don't call it an environment
[02:33] <thumper> this is going to fuck so many people off
[02:33] <rick_h_> again, implementation detail to the user
[02:33] <rick_h_> why?
[02:34] <rick_h_> I think if you list it out there's a whole lot less pain to deal with this way than trying to tell apart magic environments from non-magic environments across users/scripts/cli
[02:34] <thumper> hmm...
[02:35] <thumper> however...
[02:35] <thumper> renaming the function doesn't stop the problem
[02:35] <thumper> juju server destroy foo --force -y
[02:35] <thumper> could still leave environments running but dead
[02:35] <rick_h_> then it needs to clean them up before it dies or else block and stop and refuse to die
[02:35] <thumper> juju server destroy foo --force -y --trust-me
[02:36] <rick_h_> until those envs are gone
[02:36] <thumper> --force doesn't fail if the API is broken
[02:36] <rick_h_> ic
[02:36] <thumper> not sure --force even tries
[02:36]  * thumper looks
[02:36] <thumper> 	// If --force is supplied, then don't attempt to use the API.
[02:36] <thumper> 	// This is necessary to destroy broken environments, where the
[02:36] <thumper> 	// API server is inaccessible or faulty.
[02:37] <rick_h_> you know sabdfl will want it to be like his locking spec then.
[02:37] <rick_h_> thumper: you'll have to have a code or something to enter with giant warnings like this block stuff getting implemented
[02:38] <rick_h_> thumper: see https://docs.google.com/a/canonical.com/document/d/1oBZ2oIZOok64_QbWVPfY5Q2I053peESPZYtKSdF_L6E/edit for the original stuff on it
[02:38] <thumper> rick_h_: that didn't make sense
[02:39] <rick_h_> thumper: saying that if --force is going to potentially do bad things to running envs ^ document and https://docs.google.com/a/canonical.com/document/d/1XFYlNGmQH7-X68IXhdxsANwHN6DgAL_RMn7IDK7ZbJc/edit will come into play
[02:39] <rick_h_> thumper: well, they should come into play
[02:39]  * thumper is looking
[02:41] <thumper> rick_h_: the problem with all these solutions is they don't take into account the --force option
[02:41] <thumper> as it lives now
[02:41] <thumper> perhaps we have to remove the --force option altogether
[02:41] <rick_h_> thumper: right, but they're all trying to work in the space of your problem so whatever you do should take into account all of that
[02:41] <thumper> rick_h_: really this behaviour is outside the scope of what we are doing
[02:41] <thumper> and we have blocks now
[02:41] <rick_h_> thumper: possibly, or provide --force via a third party tool like the stuff to remove juju now
[02:41] <thumper> which anastasiamac_ has been doing
[02:42] <thumper> I think her current work addresses some of this
[02:42] <rick_h_> thumper: right, agree with that
[02:42] <thumper> rick_h_: I think perhaps a developer plugin, like the juju-nuke plugin
[02:42] <rick_h_> just saying it should fit whatever you end up doing as well. e.g. don't make it easy for users to accidentally make envs go boom that should not have
[02:42] <rick_h_> thumper: +1
[02:42] <thumper> fark...
[02:43] <thumper> how to get all this done sanely and quickly...
[02:43] <rick_h_> but get it right vs fixing it later :)
[02:43] <thumper> yeah...
[02:43] <thumper> fuck fuck fuck fuck fuck
[02:44] <thumper> shit
[02:44] <thumper> rick_h_: I was feeling pretty happy with this document before
[02:45] <rick_h_> remeber, "I love my job I love my job"
[02:45] <thumper> and now it is all screwed
[02:45] <thumper> thanks
[02:45] <rick_h_> sorry man, you asked for feedback. :/
[02:45] <thumper> don't get me wrong, I appreciate the feedback
[02:46] <thumper> it is just I'm getting real sick of speccing all this out
[02:50] <rick_h_> thumper: let me know if there's anything I can do to help. I really care/want this to come out awesome and happy to help.
[02:50] <rick_h_> thumper: but been on the road 12 hrs today so going to go to bed and crash.
[02:52] <thumper> rick_h_: ack
[03:07]  * thumper heads away from the laptop to think this over and reread the spec with fresh eyes
[03:40] <wallyworld> sinzui: i saw the precise bug. i added some input. i suspect an out of date apt mirror, but could be wrong
[03:41] <sinzui> wallyworld, aws, joyent, and hp?
[03:41] <wallyworld> sinzui: before i committed the previous fix, i tested on aws. the bug refers to an aws CI test. i just now tested with AWS again
[03:41] <wallyworld> so the CI run fails on AWS
[03:42] <sinzui> wallyworld, yes
[03:42] <wallyworld> but i have no trouble running up an aws env
[03:43] <wallyworld> but theory about an apt mirror out of date is just a theory
[03:43] <wallyworld> i could be totally off the mark
[03:43] <sinzui> aws got
[03:43] <sinzui> Unpacking cloud-image-utils (from .../cloud-image-utils_0.27-0ubuntu9~ctools0_all.deb) ..
[03:44] <wallyworld> it's cloud-utils we are worried about
[03:44] <wallyworld> https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/tools
[03:45] <wallyworld> cloud-archive-utils 	0.1-0~35~ubuntu12.04.1 	Ubuntu Cloud Archive Team (2015-02-13)
[03:45] <sinzui> waigani, Removing cloud-utils ...
[03:45] <wallyworld> the metadata for cloud-utils was wrong, and the fix is in the above
[03:45] <wallyworld> if an old cloud-utils is used, the issue as per the failed CI test occurs
[03:46] <thumper> wallyworld: got a few minutes?
[03:46] <wallyworld> the issue is that installed cloud-image-utils causes cloud-utils to be removed
[03:46] <thumper> sinzui: RE: the debug logging bug, I'm pretty sure it is environmental
[03:46] <thumper> sinzui: and "hai"
[03:46] <thumper> wallyworld: I want to run some ideas past you
[03:46] <sinzui> wallyworld, I just attached the cloud-init-output log to https://bugs.launchpad.net/juju-core/1.22/+bug/1423036
[03:46] <mup> Bug #1423036: precise services cannot be deployed (again) <ci> <precise> <regression> <juju-core 1.22:Incomplete> <https://launchpad.net/bugs/1423036>
[03:47] <wallyworld> i'm confused as to why i can run up an AWS env ok, but CI fails
[03:47] <thumper> wallyworld: same region?
[03:48] <thumper> sinzui, wallyworld: I have experienced differences in AWS over different regions before
[03:48] <thumper> not sure if they still operate weirdly
[03:49] <sinzui> thumper, good example. wallyworld I think this case is broader since the precise machine in Hp and precise tests in joyent also failed
[03:49] <sinzui> wallyworld, I know mirrors should update every day, but some can be a week behind
[03:50] <sinzui> but for all 3 to be behind? that is surprising
[03:51] <sinzui> wallyworld, I also blew away the lxc cache on the precise lxc machine
[04:04] <sinzui> wallyworld, https://launchpad.net/ubuntu/trusty/amd64/cloud-image-utils says the new cloud-image-utils is *proposed* not updates as cloud images require
[04:06] <wwitzel3> thumper: https://bugs.launchpad.net/juju-core/+bug/1413052 feedback on my reply when you have a second
[04:06] <mup> Bug #1413052: juju status hangs <status> <juju-core:Triaged> <https://launchpad.net/bugs/1413052>
[04:09] <wallyworld> sinzui: your aws deployment is indeed pulling out of date cloud-utils. I added some info to bug. But I don't know enough packaging and the repos involved
[04:10] <wallyworld> there's different data here http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/precise-updates/cloud-tools/main/binary-amd64/Packages and here https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/tools
[04:10] <wallyworld> the latter is up to date, the former is out of data
[04:10] <wallyworld> date
[04:10] <wallyworld> why my AWS deployment works I have no idea; I would have though it would be consistent
[04:11] <sinzui> wallyworld, I can see the joyent pulled the old package from the real archive, but Lp does agree the new package arrived a few days ago
[04:12] <sinzui> unless joyent, aws, and hp have proxies between ctools
[04:28] <sinzui> wallyworld, I need to sleep. When I look at http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/precise-updates/cloud-tools/ and everything below, all the data is from last year. no files mention the new packages
[04:30] <sinzui> wallyworld, but I can see that proposed does know about the new packaged http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/precise-proposed/cloud-tools/
[04:32] <sinzui> Maybe the archive is not really at the state Lp thinks it is. This is true for releasing juju. I need to count the packages in the archive because Lp doesn't read the file systems
[04:36] <wallyworld> sinzui: do you have any idea about the archive issues?
[04:36] <thumper> wallyworld, waigani: we should hold off on the destroy-environment landing until we get some agreement on the spec
[04:37] <thumper> wallyworld: please hold off any more reviewing until you, me and waigani have had a chat
[04:39] <thumper> wallyworld: did you get either of those?
[04:40] <wallyworld> those what?
[04:40] <wallyworld> stupid freenode conection :-(
[04:40] <thumper> wallyworld, waigani: we should hold off on the destroy-environment landing until we get some agreement on the spec
[04:40] <thumper> wallyworld: please hold off any more reviewing until you, me and waigani have had a chat
[04:40] <wallyworld> sure
[04:40] <thumper> ta
[04:40] <wallyworld> thumper: is that due to the conversation with rick?
[04:41] <thumper> yup
[04:41] <wallyworld> i was wondering about that
[05:57] <anastasiamac_> wallyworld: dunno if u saw it  (with ur connection misbehaving and all)...
[05:58] <anastasiamac_> wallyworld: re-proposed PTAL http://reviews.vapour.ws/r/941/
[06:02] <wallyworld> ok, might have to be after soccer
[08:53] <TheMue> morning
[09:17] <jam> fwereade_: when you're around, give me a ping
[09:20] <fwereade_> jam, heyhey, just finished with domas
[09:23] <jam> fwereade_: hey, brb. I'll be in leader-election hangout when you're available just using the restroom quickly
[09:23] <TheMue> dimitern: ping
[09:24] <dimitern> TheMue, hey
[09:25] <TheMue> dimitern: seen your comments on GH, some are already done in the PR
[09:26] <TheMue> dimitern: regarding the MachinePortsResults, this type relies on MachinePorts which is older and looks different than our networking stuff
[09:26] <TheMue> dimitern: but still move anything related to networks?
[09:27] <TheMue> dimitern: at least it uses a NetworkTag
[09:27] <TheMue> dimitern: in MachinePorts
[09:27] <dimitern> TheMue, yeah, it's older but still networking related and used by the firewaller IIRC
[09:27] <dimitern> dooferlad, ping
[09:27] <TheMue> dimitern: it is, yes
[09:27] <TheMue> dimitern: ok, so will move it too
[09:27] <dooferlad> dimitern: Hi, was just looking at that bug
[09:27] <dimitern> TheMue, cheers
[09:28] <dimitern> dooferlad, hey! so the foreport to 1.22 should be easy, but let's talk about the fix during/after standup
[09:28] <dooferlad> dimitern: will do
[09:29] <dimitern> dooferlad, ta
[10:03] <dimitern> TheMue, dooferlad, sorry, I'll be ~5m late for standup
[10:28] <jam> fwereade_: http://reviews.vapour.ws/r/949/ for some of the cleanups that I've done so far.
[10:49] <jam> fwereade_: ping
[10:50] <fwereade_> jam, sorry, missed the review link
[10:50] <jam> fwereade_: np. Not urgent. I wanted to check something else with you
[10:50] <jam> specifically what we found with livesource.go
[10:50] <fwereade_> jam, the for loop?
[10:50] <jam> where it was using wg.Add() wg.Done() which means that the goroutine is blocked if you never call the func
[10:50] <fwereade_> jam, ah yes
[10:51] <jam> I have a test that fails, by observing that source.Changes() channel is never closed if you call source.Stop() but don't call the func.
[10:51] <jam> I'm trying to figure out what we want instead of the for loop. Is it that we need to go to a full func loop() ?
[10:51] <perrito666> morning all
[10:51] <jam> hi perrito666
[11:00] <jam> fwereade_: thoughts on what the correct fix is? I think we talked about NewLiveSource needing its own Tomb
[11:01] <jam> or alternatively use a channel implementation
[11:01] <jam> (create a channel, close it in the func(), rather than wg.Add, select over that channel and the tomb so we know when we need to clean up.)
[11:02] <jam> I think with a channel we don't have to have a full "loop" but we probably need a Tomb, and if we have a tomb, going to a loop() is probably clearer code as it follows the model of similar code.
[11:05] <fwereade_> jam, yes, I think we do in general just want our own tomb
[11:05] <fwereade_> jam, hence for loop
[11:06] <fwereade_> jam, and I think it's generally nice practice to pull the loop out into its own method, returning an error, for consistency's sake if nothing else
[11:06] <jam> k
[11:16] <fwereade_> jam, I think I remember how to do it "right"
[11:17] <fwereade_> jam juju/state/watcher.Stop(Stopper, *tomb.Tomb)
[11:17] <fwereade_> jam, so if it were in a less unhelpfully-samed package
[11:18] <fwereade_> jam, it would be clear that goroutine-wrapping-some-resource is a common pattern
[11:18] <fwereade_> jam, and that Stop and EnsureErr are both generally useful for any components that wrap one resource
[11:19] <fwereade_> jam, so
[11:20] <fwereade_> defer self.tomb.Done()
[11:20] <fwereade_> defer resource.Stop(self.resource, &self.tomb)
[11:20] <fwereade_> self.tomb.Kill(self.loop())
[11:21] <fwereade_> jam, ...along with
[11:21] <fwereade_> case _, ok := <-self.resource.Changes():
[11:21] <fwereade_>  
[11:21] <fwereade_>     if !ok {
[11:22] <fwereade_>         return resource.EnsureErr(self.resource)
[11:22] <fwereade_>     }
[11:22] <jam> fwereade_: "resource" isn't in livesource.go, you just mean in general?
[11:23] <fwereade_> jam, yeah, the current package is state/watcher
[11:23] <fwereade_> jam, but Stop and EnsureErr aren't specific to watchers
[11:24] <jam> fwereade_: RelationUnitsWatcher only has Stop Err and Changes
[11:24] <fwereade_> jam, oh wait maybe watchers have Stop() methods where workers have Kill() and Wait()?
[11:24] <fwereade_> jam, gaah
[11:24] <fwereade_> jam, I think the worker interface is saner
[11:25] <fwereade_> jam, but, see? these fixes become fractally tentacular if we'renot careful :(
[11:25] <jam> :)
[11:25] <jam> yak shaving
[11:25] <fwereade_> jam, indeed
[12:46] <fwereade> jam, (btw: LGTM as is, despite quibbling, progress not perfection)
[13:02]  * TheMue is out for lunch
[13:03] <TheMue> dimitern: updated PR is in, see review board
[13:05] <dimitern> TheMue, cheers, will look soon
[14:00]  * dimitern steps out for ~1h
[14:05] <perrito666> why are we getting so many curses?
[14:08] <jw4> perrito666: curses?
[14:08] <perrito666> from CI
[14:08] <jw4> i.e. blockers? lol
[14:27] <marcoceppi> any chance I can get a senior reviewer to took at this? http://reviews.vapour.ws/r/926/
[14:32] <mgz> marcoceppi: looks good to me too, is eric's stamp not okay?
[14:32] <marcoceppi> mgz: I was told to wait for a more sneior reviewer
[14:34] <TheMue> marcoceppi: done
[14:35] <marcoceppi> ta
[14:36] <perrito666> TheMue: i am not being an incredible fan of http://reviews.vapour.ws/r/947/diff/2 why is it that you are not adding a method to apihostportresults that returns  Servers as NetworkHostPorts ?
[14:39] <TheMue> perrito666: could be a helper too, yes. so far concentrated on structs or nested slices of hostport
[14:41]  * TheMue sees our already large params with lots of conversion helpers in the future ...
[14:42] <perrito666> TheMue: well borrowing from python :p better explicit
[14:42] <perrito666> TheMue: what botters me the most is that I see a lot of params.NetworkHostPorts(someparam.Servers)
[14:42] <perrito666> which is a bit noisy
[14:43] <TheMue> perrito666: yeah, you get network, want params, get params, want network
[14:44] <perrito666> so basically what I mean is, you are using params.NetworkHostPorts to convert a member of params.APIHostPorts :)
[14:44] <perrito666> sounds like that should be happening on params :p
[14:45]  * perrito666 laughs because param is the sound used in spanish for tada
[14:47] <TheMue> perrito666: could you point me to file and line
[14:48] <perrito666> TheMue: gimme a sec, trying to beat some sense into reviewboard :p
[14:48] <TheMue> hehe
[14:49] <perrito666> ohh ffs http://reviews.vapour.ws/r/947/diff/# file: api/state.go line 80
[14:49] <perrito666> sometimes I really hate that ui
[14:52] <TheMue> perrito666: thx, yes, here it creates the network.HostPorts out of the params.HostPorts
[14:53] <TheMue> perrito666: and those are [][]<mypackage>.HostPort which are struct, gna
[14:54] <perrito666> gna?
[14:56] <TheMue> inner sound of "excitement" about this construct
[14:56] <TheMue> :D
[15:02] <perrito666> wwitzel3: ?
[15:06] <perrito666> TheMue: I added the comment in the code
[15:07] <TheMue> perrito666: great, thx
[15:42] <dimitern> TheMue, hey, did you see my review about the live tests?
[15:43] <dimitern> dooferlad, ping
[15:43] <TheMue> dimitern: yep, just doing it with local provider. looks good so far.
[15:43] <dimitern> TheMue, cool!
[15:44] <dimitern> TheMue, I'll double check it here as well
[15:44]  * dimitern doesn't want more regressions :)
[15:44] <TheMue> dimitern: great, thx
[15:44] <TheMue> hehe
[15:44] <TheMue> dimitern: yeah, and this change already went too large. not in the sense of structure, but changed places.
[15:45] <dimitern> TheMue, yeah, but I'd rather get it landed :)
[15:47] <sinzui> dooferlad, how goes the backport of bug 1416928 to 1.22?
[15:47] <mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Triaged by dooferlad> <juju-core 1.21:Fix Released by dimitern> <juju-core 1.22:Triaged by dooferlad> <https://launchpad.net/bugs/1416928>
[15:55] <dimitern> sinzui, he mailed me a couple of branches with the backports for 1.22 and trunk; I'm checking them now
[15:56] <dimitern> oops - s/backports/foreports/ that is
[16:01] <sinzui> dimitern, bug 1420049 is now confirmed to be a regression with 1.20. We need someone to address it.
[16:01] <mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1420049>
[16:01]  * sinzui would also ask natefinch to make arrangements, but he might be lost in the snow
[16:01] <dimitern> sinzui, I'll have a look
[16:05] <dooferlad> dimitern: sinzui: Happy to apply the fix to 1.20 as well.
[16:06] <dimitern> dooferlad, which fix?
[16:07] <dooferlad> dimitern: Oh, hang on, I got my bug numbers muddled! Thought both comments were about 1416928
[16:07] <dimitern> dooferlad, yeah :)
[16:07] <dimitern> dooferlad, I've pulled your branches with the foreports and once I'm done with live testing TheMue's changes I'll look at yours
[16:08] <dooferlad> dimitern: turns out tests run better when the heatsink isn't dangling off your northbridge. Top computer stability tip.
[16:08] <sinzui> dooferlad, 1.20 is not broken and we aren't release it any more. just 1.22 and master need the love
[16:08] <dimitern> dooferlad, LOL :)
[16:08] <dooferlad> dimitern: are there instructions for live testing, or is it in your head?
[16:09] <dimitern> dooferlad, in my head, but I can try to summarize them, good point
[16:09] <dimitern> dooferlad, i'll send them by mail
[16:09] <dooferlad> dimitern: thanks.
[16:26] <TheMue> dimitern: just had 1:1 and during this time I've seen an error on EC2. have to look for the reason now.
[16:27] <TheMue> dimitern: hmm, maybe already found it
[16:28] <dimitern> TheMue, I'm testing on maas first
[16:28] <TheMue> dimitern: ah, fine, so different providers
[17:26] <TheMue> dimitern: thought I found it but cannot get the reason for my "environment uuid was not supplied"
[17:27] <dimitern> TheMue, you can easily test if your changes caused this (but I doubt it) - switch to master, rebuild, bootstrap :)
[17:28] <TheMue> dimitern: yes, will check it this way
[17:29] <dimitern> dooferlad, please go ahead and propose a PR for the 1.22 foreport
[17:29] <dooferlad> dimitern: will do
[17:29] <dimitern> dooferlad, cheers
[17:29] <dimitern> TheMue, live tests on maas pass ok
[17:29] <dimitern> TheMue, trying manual now and then ec2 and local
[17:29] <TheMue> dimitern: ah, great info, thanks. seems to be local
[17:30] <TheMue> dimitern: local in the sense of "here", not the provider
[17:30] <TheMue> ;)
[17:30] <dimitern> :)
[17:30] <cherylj> katco - can you take a quick look at my changes for featuretests: http://reviews.vapour.ws/r/945/
[17:30] <katco> cherylj: sure thing
[17:33] <katco> cherylj: just one minor thing, but it looks great! thank you!
[17:35] <dimitern> dooferlad, thanks, but can you change the PR description to mention this is a foreport of the original PR #1616 ?
[17:35] <dooferlad> dimitern: sure
[17:35] <dimitern> ..for 1.22
[17:35] <dimitern> dooferlad, ta!
[17:37] <cherylj> thanks, katco.  While I'm in there, I guess I should update the name of the suite to match the new filename
[17:38] <katco> cherylj: ah good idea, i missed that
[17:38] <dimitern> dooferlad, have you tried live testing this by bootstraping a manual environment to a machine with and without the lxc package installed?
[17:38] <dooferlad> dimitern: no, I just ran the built in tests
[17:39] <dimitern> dooferlad, do you know how to do it?
[17:40] <dooferlad> dimitern: think so. The bug report is quite clear.
[17:43] <dimitern> dooferlad, sweet, please give it a try and let me know how it went
[17:43] <dooferlad> dimitern: will do
[17:50] <perrito666> the least flooded part of my way home https://pbs.twimg.com/media/B-JP1USIIAAmYjv.jpg:large
[17:53] <TheMue> dimitern: it looks like you can slap me, the error seems to be in front of the screen
[17:53] <TheMue> dimitern: it's nice to create new build but the path should be set to use them *facepalm*
[17:56] <dimitern> TheMue, so what's the issue?
[17:57] <TheMue> dimitern: none anymore, currently it's running find. but during the last try with the error above I used some old and it seems instable build from last year
[17:57] <TheMue> dimitern: path had been set wrong, not using my fresh builds
[17:58] <dimitern> TheMue, right :) that's why I have my rebuild-juju script always in $PATH
[17:58] <TheMue> dimitern: yep, changed it too. dumb error
[18:03] <dimitern> TheMue, manual bootstrap also works
[18:04] <TheMue> dimitern: EC2 looks fine so far too, waiting for the latest steps to complete
[18:05]  * TheMue has to add this in his tool too, "jdt live-test amazon" or "jdt live-test local" etc.
[18:07] <TheMue> Interesting, just read, Lenovo creates super-computer based on ARM
[18:08] <perrito666> TheMue: well its always good not having to drag all the baggage x86 has
[18:08] <TheMue> perrito666: +1
[18:09] <perrito666> I guess not before long laptops with ARMs will be decent enough to use as a laptop
[18:10]  * perrito666 suddenly remembers when there was via cyrix against intel or even ppc as desktop options (I am getting old)
[18:10] <TheMue> dimitern: so, EC2 works fine too
[18:11] <dimitern> TheMue, what did you test?
[18:11]  * TheMue remembers his time with his 12" PowerPC notebook
[18:11] <TheMue> dimitern: standard scenario, wp and mysql *lol*
[18:11] <perrito666> TheMue: g4?
[18:11] <TheMue> perrito666: exact
[18:12] <perrito666> yup, my favorite form factor to the day
[18:12] <perrito666> I was really sad to part with that thing
[18:12] <TheMue> perrito666: I liked it a lot, and felt special with all those intels around
[18:13] <TheMue> perrito666: they will come with an ARM, lets wait
[18:13] <perrito666> I used to win an argument against my university teacher on why visual basic on windows was not a reasonable requirement to ask for a student (they would supply a free licence) I just handed to him saying, ok, ill use it if you manage to install it on my coputer
[18:15] <TheMue> hehe
[18:16] <dimitern> TheMue, add-relation, waiting for them to start, exposing, trying to open wp from a browser? and checking machine logs for suspicious ERROR and WARNING, right?
[18:16] <TheMue> dimitern: yep
[18:16] <dimitern> TheMue, sweet!
[18:16] <TheMue> dimitern: already started to setup a wp presence
[18:16] <dimitern> TheMue, I'll stamp it then - all my live tests went fine
[18:16] <TheMue> dimitern: cool
[18:18] <dimitern> TheMue, some of the issues you've resolved already - just sync up with menn0 and perrito666
[18:19]  * perrito666 diffs with TheMue 
[18:20] <TheMue> dimitern: yes, mennos is already done, and I like perrito666s idea. that will go in and be tested befor I push
[20:26] <perrito666> natefinch: this change for de defer of the readcloser you added is a nightmare :p
[20:41] <thumper> sinzui: can we chat plz?
[20:41] <sinzui> thumper, yes
[20:41]  * thumper starts a hangout
[20:43] <thumper> sinzui: pm'ed the link
[20:56] <perrito666> natefinch: could you take another look?
[21:45] <perrito666> k ppl EOD but will be back later
[23:21] <anastasiamac_> perrito666: this street looks awful :( r u on higher ground?
[23:59] <jw4> OCR PTAL : http://reviews.vapour.ws/r/951/  <--- Running Actions while unit is in hook error state, without clearing the hook error