[00:48] <davecheney> thumper: i figured out the final test failure on my branch
[00:48] <davecheney> here is a hint
[00:48] <davecheney> lucky(~/src/github.com/juju/juju) % jujud version
[00:48] <davecheney> 1.26-alpha1
[00:52] <davecheney> cherylj: thumper do you know if we have a test for "juju version"
[00:52] <davecheney> or "jujud version"
[00:53] <davecheney> i suspect that we do not
[00:55] <thumper> um... wat?
[00:55] <thumper> oh
[00:56] <thumper> I see that both juju version and jujud version are fully qualified with series and arch
[01:32] <davechen1y> thumper: https://github.com/juju/cmd/pull/24
[01:32] <davechen1y> little one for you
[01:32]  * thumper looks
[01:33] <thumper> LGTM
[01:36] <davechen1y> thumper: ta
[01:41] <davechen1y> thumper: https://github.com/juju/juju/pull/3545
[01:42] <davechen1y> complimentary change in juju/juju
[01:42] <thumper> shipit
[01:43] <davechen1y> thumper: do you know if the version subcommand is sahred between cmd/juju and cmd/jujud
[01:43] <davechen1y> tryign to figure out where it is registered is a bugger
[01:43] <davechen1y> i'm trying to figure out if i need to add more tests
[01:43] <davechen1y> or if there is only one place version is created
[01:44] <thumper> the version is passed in when the primary super command is created
[01:44]  * thumper double checks
[01:45]  * thumper gets a bad feeling
[01:47] <davechen1y> do tell
[01:52]  * thumper cries 
[01:52]  * thumper adds another item to the shit list
[01:53] <thumper> davechen1y: I'm actually tring to find out where the version is hooked into the juju cmd
[01:53] <thumper> and it isn't obvious
[01:53] <davechen1y> it is not
[01:53] <davechen1y> this is the bug blocking landing the versin.Current branch
[01:53] <davechen1y> a lot of code relies on the output of 'jujud version'
[01:53] <davechen1y> being specific form
[01:54] <davechen1y> please assign me the tech debt card
[01:54] <davechen1y> i'l fix it
[01:56] <thumper> the tech debt card is a different one, cmd/juju/commands badrun func needs to die
[01:57] <thumper> ah ha
[01:57] <thumper> cmd/supercommand.go
[01:58] <thumper> that is where the version string is added
[01:58] <thumper> davechen1y: and that file has the run notifier too
[02:00] <thumper> davechen1y: if I have a select block where some of the values are channels and others are functions that return channels, will all the functions get executed?
[02:00] <thumper> or does it depend?
[02:01] <thumper> davechen1y: your stress.sh helper seems to indicate that it will always be called
[02:04] <davechen1y> selection happens in two phases
[02:05] <davechen1y> 1. all expressions are evaluated, returning channels that may be selectable
[02:05] <davechen1y> 2. the other stuff
[02:05] <davechen1y> so if you ahve
[02:05] <davechen1y> case <- c:
[02:05] <davechen1y> case <- f():
[02:05] <davechen1y> then f() will be evaluated
[02:05] <davechen1y> that phase happens in order, from top to bottom
[02:05] <davechen1y> so case <- a():
[02:05] <davechen1y> case <- b():
[02:05] <davechen1y> a() will be evalusted, then b()
[02:06] <thumper> ok
[02:06] <thumper> my test adds a marker when the func is called, and returns a channel
[02:06] <thumper> just making sure that the func is always called before channels checked
[02:06] <thumper> this is good
[02:06] <thumper> makes for a stable test :)
[02:07] <davechen1y> always called, and always in the same order
[02:08] <thumper> coolio
[02:08] <davechen1y> thanks for the supercmd tip
[02:08] <davechen1y> i'll make sure we're testing the expected output there
[02:14] <thumper> the juju/juju/cmd/supercommand.go just passes in the string
[02:14] <thumper> to use as the version
[02:15] <thumper> this is just echoed from the juju/cmd package
[02:15] <thumper> when someone uses the version command
[02:17] <axw> wallyworld: is there a bug for tests failing on wily?
[02:19] <axw> wallyworld: (I can look if you don't know off the top of your head ...)
[02:45] <thumper> axw: not sure if there is a bug, but there are two causes that leap to mind
[02:45] <thumper> 1. errors changing text and our tests are too strict
[02:46] <thumper> 2. scheduling changes bringout out timing related errors
[02:46] <thumper> bringing
[02:46] <axw> thumper: ok, thanks
[02:46] <axw> running a wily container now to run the tests
[02:46]  * thumper thinks
[02:47] <thumper> in the past, I think there were other problems attempting to run the unit tests in containers
[02:47] <thumper> not sure what it was though
[02:47] <thumper> nor sure if they are still there
[02:48] <axw> thumper: AFAIK they were all timing related
[02:48] <axw> will find out shortly :)
[02:48] <thumper> :)
[03:06] <davechen1y> ... mismatch at ["services"]["mysql"]: length mismatch, 4 vs 5; obtained map[interface {}]interface {}{"charm":"local:quantal/mysql-1", "exposed":false, "relations":map[
[03:06] <davechen1y> interface {}]interface {}{"server":[]interface {}{"wordpress"}}, "units":map[interface {}]interface {}{"mysql/0":map[interface {}]interface {}{"agent-state":"allocating"
[03:06] <davechen1y> , "machine":"1"}}}; expected map[interface {}]interface {}{"relations":map[interface {}]interface {}{"server":[]interface {}{"wordpress"}}, "service-status":map[interfac
[03:06] <davechen1y> e {}]interface {}{}, "units":map[interface {}]interface {}{"mysql/0":map[interface {}]interface {}{"agent-state":"allocating", "agent-status":map[interface {}]interface
[03:06] <davechen1y> {}{}, "machine":"1", "workload-status":map[interface {}]interface {}{}}}, "charm":"local:quantal/mysql-1", "exposed":false}
[03:06] <davechen1y> any ideas ?
[03:06] <davechen1y> for some reason updaing github.com/juju/cmd causes this test to fail because there is an additional status element
[03:37] <davechen1y> OH FUCKING FUCK
[03:37] <davechen1y> https://github.com/juju/cmd/commit/2933b3ffd9116713d6da61494cdc789889100cb7
[03:37] <davechen1y> yaml.v1 and yaml.v2 treat these structs differently
[03:39] <davechen1y> thumper: https://github.com/juju/cmd/pull/25
[03:40] <thumper> :(
[03:41] <axw> thumper: I dunno if someone already fixed the issues, but tests run fine on master with wily in an LXC container
[03:41] <thumper> axw: well that is good
[03:41] <axw> wallyworld_: ^^
[03:41] <thumper> I still get failures running locally on trusty with 1.5
[03:41] <wallyworld_> hmmm
[03:42] <axw> thumper: FWIW I was using go 1.5 from the golang-go package
[03:42] <davechen1y> thumper: tests do not pass under Go 1.5
[03:42] <davechen1y> peergrouper is still a shitshow
[03:42] <thumper> axw: you may want to retry the peergrouper tests
[03:42] <axw> davechen1y: does for me - perhaps more frequent failures though?
[03:42] <wallyworld_> axw: i was only going by what curtis told me
[03:42] <thumper> sometimes they pass, sometimes not
[03:42] <davechen1y> axw: 100% failure rate across amd64, ppc64 and arm64
[03:43] <davechen1y> thumper: http://reviews.vapour.ws/r/2945/
[03:43] <davechen1y> please, it's quite urgent as it is blocking me
[03:43] <axw> davechen1y: definitely not 100% for me. I'm using 1.5 and it passes.
[03:43] <thumper> davechen1y: :-( what is so different between v2 and v1?
[03:44] <davechen1y> thumper: they handle empty fields differently
[03:44] <thumper> ugh
[03:44] <wallyworld_> axw: could you look at the jenkins job and see what failures there are there compared with your test run?
[03:44] <davechen1y> http://juju-ci.vapour.ws:8080/job/github-merge-juju/5150/console
[03:44] <davechen1y> we can try again later
[03:45] <axw> wallyworld_: sure
[03:45] <wallyworld_> ty
[03:45] <davechen1y> i'll put it on my list to take over the transition from mgz
[03:45] <davechen1y> thumper: http://juju-ci.vapour.ws:8080/job/github-merge-juju/5150/console
[03:47] <thumper> davechen1y: ack, back to v1, when we move juju/juju to v2, we can fix the tests
[03:51] <davechen1y> thumper: ta
[03:52] <davechen1y> thumper: how's that tech debt backlog ?
[03:52] <thumper> growing
[03:52] <thumper> davechen1y: https://canonical.leankit.com/Boards/View/116651667#workflow-view
[03:53] <davechen1y> lotta red
[03:53] <thumper> :)
[03:59] <davechen1y> https://github.com/juju/cmd/pull/25
[03:59] <davechen1y> can someone submit this for me
[03:59] <davechen1y> bot has gone awol
[04:05]  * thumper explodes
[04:13] <davechen1y> landing bot has borke
[04:13] <davechen1y> http://juju-ci.vapour.ws:8080/job/github-merge-juju-cmd/5/console
[04:21] <davechen1y> wallyworld: can you kick the bot please
[04:21] <davechen1y> it's not picking up jobs anymore
[04:21] <wallyworld> all jobs or just yours?
[04:21] <wallyworld> it looks for a Build failed: message
[04:21] <wallyworld> otherwise it will ignore resubmits
[04:22] <davechen1y> wallyworld: it won't get that message
[04:22] <davechen1y> 'cos it died
[04:22] <davechen1y> wallyworld: http://juju-ci.vapour.ws:8080/job/github-merge-juju-cmd/5/console
[04:22] <wallyworld> so manually type in "Build failed: foo" into gh comment on the pr
[04:22] <davechen1y> \o/
[04:22] <davechen1y> thanks for the tip
[04:22] <wallyworld> and then a subsequent $$merge$$ will trigger
[04:22] <wallyworld> i know it's sucky
[04:23] <davechen1y> meh
[04:23] <davechen1y> that works
[04:23] <wallyworld> yay
[04:23] <davechen1y> at least I can fix it myself
[04:23] <davechen1y> without having to nag you
[04:23] <wallyworld> sure :-)
[04:23]  * thumper is done
[04:55] <axw> wallyworld: so it's possible for the peergrouper tests to error if the set of state server machines is non-empty... nfi how that would be the case. doesn't appear to be wily-specific, and I haven't been able to repro in my container
[04:55] <axw> wallyworld: I'll keep poking
[05:01] <mup> Bug #1507867 opened: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1507867>
[05:54] <wallyworld> axw: thanks for looking into it - those peer grouper tests are horrid
[06:22] <axw> wallyworld: there's only one test that's using a real mongo connection in a meaningful way. I'm going to move that one to featuretests, and remove the remnants of JujuConnSuite from the others
[08:56] <wallyworld> dimitern: could you add any notes / progress to that bug so other folks can stay in the loop? maybe add in a sentence or 2 the solution with cidr that is being looked at?
[08:58] <dimitern> wallyworld, sure
[08:58] <wallyworld> ty, you rock
[08:59] <dimitern> wallyworld, well it's my own mess to begin with ;/
[08:59] <wallyworld> our mess, we all own juju :-)
[09:00] <dimitern> :D that's better, yeah
[09:02] <dooferlad> frobware: hangout?
[09:02] <frobware> omw
[14:46] <wwitzel3> ericsnow, katco`, natefinch: where did we fall on allowing you to pass register just the workload class name and ID, because as I write out these notes again, it feels really odd to be defining it in the metadata AND then passing all of that in on the command line
[14:47] <ericsnow> wwitzel3: I thought we were dropping the redundant CLI arg
[14:48] <wwitzel3> ericsnow: ok, current register doesn't do that it seems
[14:48] <ericsnow> wwitzel3: I may be wrong :)
[14:48] <katco`> wwitzel3: yeah we agreed on dropping it, but probably got lost in translation as the team was scrambling. it's fine for v1
[14:48] <katco`> wwitzel3: we can change in v2 if necessary
[14:48] <katco`> wwitzel3: remember, mvp
=== katco` is now known as katco
[14:55] <TheMue> dimitern: thx
[14:56] <cherylj> dimitern: did you see my question about bug 1483879?
[14:56] <mup> Bug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <destroy-machine> <landscape> <maas-provider> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1483879>
[15:04] <dimitern> cherylj, looking now
[15:05] <dimitern> oh ffs
[15:05] <dimitern> this doesn't seem to be going anywhere
[15:06] <dimitern> cherylj, where's you comment?
[15:06] <dimitern> your
[15:07] <cherylj> i had sent you an email about it.  there was speculation that this had already been fixed
[15:07] <cherylj> We'd like to target it for 1.25.0
[15:08] <dimitern> cherylj, I believe it is indeed fixed
[15:08] <dimitern> cherylj, but there seems to be a communication breakdown somewhere between us and them :)
[15:08] <cherylj> Do you happen to know which commit(s) fixed it?
[15:12] <mup> Bug #1508089 opened: `juju set keystone ...` caused `hook "config-changed" failed` <juju-core:New> <https://launchpad.net/bugs/1508089>
[15:12] <dimitern> cherylj, the linked PR - https://github.com/juju/juju/pull/2548
[15:13] <cherylj> dimitern: Thanks!
[15:16] <katco> ericsnow: if master uses charm.v6-unstable, why don't we just forward-port the payload stuff from v5? why move it out?
[15:16] <katco> ericsnow: is that by design?
[15:17] <ericsnow> katco: because workloads.go really doesn't belong in the charm repo
[15:17] <katco> ericsnow: gotcha
[15:27] <katco> ericsnow: are we doing the cleanup in the feature-payloads branch?
[15:28] <ericsnow> katco: that's not quite clear to me
[15:28] <ericsnow> katco: was going to tackle that as we got closer depending on where we stood on master
[15:28] <katco> ericsnow: the question or it's not clear what the answer is?
[15:29] <ericsnow> katco: what the answer is :)
[15:29] <katco> ericsnow: i think it's fine since it's landed in 1.25. if we need to change anything there we can just branch off of 1.25
[15:30] <katco> ericsnow: maybe the only thing that gives me pause is how hard will it be to rebase the changes on top of master
[15:30] <katco> ericsnow: i'll try that first and see what we're looking at
[15:31] <ericsnow> katco: I'd say wait on the rebase until after you take care of the charm/workloads.go thing
[15:31] <ericsnow> katco: otherwise you won't be able to test the rebase
[15:31] <katco> ericsnow: how difficult it is to rebase determines where we do a new feature branch
[15:31] <ericsnow> katco: k
[15:32] <katco> ericsnow: i.e. it's the difference between "start from master, pull in workload feature" or "start from 1.25 and rebase to master"
[17:16] <lazypower> wwitzel3, ubuntu@xps13:~$ juju --version
[17:16] <lazypower> 1.26-alpha1-trusty-amd64 - the 1.25 branch reports version as if it were trunk, is this intended behavior?
=== lazypower is now known as lp|lunch
[17:22] <wwitzel3> lp|lunch: not sure, does the same for me, so it is ok for what we are doing
[17:24] <katco> wwitzel3: lp|lunch don't think that is intentional
[17:57] <mup> Bug #1508089 changed: `juju set keystone ...` caused `hook "config-changed" failed` <juju-core:Invalid> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1508089>
=== lp|lunch is now known as lazyPower
[18:07] <lazyPower> ack
[18:07] <lazyPower> just making sure its consistent. I went to verify that i had the proper docker bin built and i saw the 1.26 alpha - its not terribly alarming, just thought i'd ping about it
[18:07] <lazyPower> er
[18:07] <lazyPower> juju bin
[18:07]  * lazyPower has that other container thing on the brain
[21:55] <alexisb> thumper, I am going to steal some time w/ cherylj before we meet
[21:55] <thumper> k
[23:32] <cherylj> hey wallyworld, I'm going through the 1.25 bugs and came across this one which I'm not sure if we should bump the priority of to get into 1.25.0:  bug 1469193
[23:32] <mup> Bug #1469193: juju selects wrong address for API <kvm> <local-provider> <lxc> <network> <sts> <juju-core:Triaged> <https://launchpad.net/bugs/1469193>
[23:32] <cherylj> wallyworld: what do you think?
[23:33] <wallyworld> cherylj: give me 5 to look, just in standup
[23:35] <cherylj> wallyworld: np, I might be on kid duty in a few, but I'll check scrollback if I miss it
[23:48] <wallyworld> cherylj: that bug is symptomatic of a class of problem that is bad and that juju has had trouble with in the past. sapphire is looking at an issue now that was fallout from attempting to deal with this sort of thing.
[23:49] <wallyworld> bug 1507867
[23:49] <mup> Bug #1507867: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1507867>
[23:50] <wallyworld> cherylj: so i'd personally like that bug you mentioned to be a 1.25 fix, if not 1.24. maybe it will be covered by the work sapphire is doing now to fix the 2nd bug above