[01:03] <davecheney> cherylj: ping
[01:03] <davecheney> 10:03 < davecheney> cherylj: what's the status of 1.25.4 ?
[01:03] <davecheney> 10:04 < davecheney> i'm building up a lot of chagnes on master that should be backported to 1.25
[01:04] <thumper> davecheney: I think you should prepare the changes for 1.25 branch
[01:04] <thumper> the question becomes whether to do one or many
[01:04] <thumper> davecheney: I hear zfs works real well with lxd
[01:07] <davecheney> thumper: should I land what I have now?
[01:07] <davecheney> when is 1.25.4 coming out ?
[01:07] <thumper> davecheney: I think some of these connection type issues are needing to be fixed in 1.25 too
[01:07] <thumper> so yes, I think you should be landing these changes on 1.25 too
[01:08] <axw> anastasiamac: thanks for review, please see my response to your issue before I go ahead
[01:08] <perrito666> sweeet master is bless
[01:09] <axw> perrito666: I hope you kicked off all your merges before you announced that
[01:09] <perrito666> axw: no pending merges from me :)
[01:09] <axw> perrito666: :p
[01:12] <alexisb> davecheney, cherylj is out for the evening
[01:17] <mup> Bug #1491399 changed: TestInstallMongodServiceExists fails on centos <centos> <ci> <precise> <regression> <test-failure> <juju-core:Fix Released> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1491399>
[01:17] <mup> Bug #1494726 changed: TestGetUsesCache different mime-type centos <centos> <ci> <test-failure> <unit-tests> <juju-core:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1494726>
[01:20] <mup> Bug #1491399 opened: TestInstallMongodServiceExists fails on centos <centos> <ci> <precise> <regression> <test-failure> <juju-core:Fix Released> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1491399>
[01:20] <mup> Bug #1494726 opened: TestGetUsesCache different mime-type centos <centos> <ci> <test-failure> <unit-tests> <juju-core:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1494726>
[01:23] <mup> Bug #1491399 changed: TestInstallMongodServiceExists fails on centos <centos> <ci> <precise> <regression> <test-failure> <juju-core:Fix Released> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1491399>
[01:23] <mup> Bug #1494726 changed: TestGetUsesCache different mime-type centos <centos> <ci> <test-failure> <unit-tests> <juju-core:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1494726>
[01:25] <davecheney> alexisb-afk: ahh, thanks
[01:27] <davecheney> thumper: do we have a error.Causes checker ?
[01:27] <davecheney> ie, rather than writing
[01:27] <davecheney> errors.Cause(err), gc.Equals, ....)
[01:27] <davecheney> can wr write
[01:28] <thumper> I don't think so...
[01:28] <davecheney> err, gc.Causes, expected
[01:28] <davecheney> i thought you were talking about adding htat way back when
[01:28] <thumper> there is jc.Satisfies
[01:28] <davecheney> that checks type
[01:28] <thumper> I'm not sure if that looks at the cause
[01:28] <davecheney> which isn't close enough
[01:28] <thumper> pretty sure we don't
[01:29] <thumper> but could be useful
[01:29] <davecheney> anyway, i have got my branch to the point that we dont' have to add all that 'request error: ' prefix nonsense
[01:29] <thumper> cool
[01:29] <davecheney> which is the whole reason params.ClientError existed -- to filter that out
[01:29] <davecheney> now we have *rpc.RequestError as a type, properly annotated all the way back out to the caller
[01:31] <thumper> :)
[01:33] <davecheney> thumper:
[01:33] <davecheney> -               c.Assert(err, gc.ErrorMatches, "permission denied")
[01:33] <davecheney> +               c.Assert(errors.Cause(err), gc.Equals, &rpc.RequestError{
[01:33] <davecheney> +                       Message: "permission denied",
[01:33] <davecheney> +                       Code:    "unauthorized access",
[01:33] <davecheney> +               })
[01:34] <thumper> nice
[01:34] <thumper> ...
[01:34] <thumper> but begs for some new checkers
[01:34] <thumper> c.Assert(err, blah.IsUnauthorized)
[01:36] <davecheney> lets see how big the diff is
[01:36] <davecheney> i dont want to change more than I have to to backport this to 1.2
[01:36] <davecheney> i dont want to change more than I have to to backport this to 1.25
[01:38] <thumper> k
[01:51] <davecheney> yeah, this attempt is generating a much smaller diff
[01:53] <mup> Bug # changed: 1497355, 1508585, 1510951, 1514877, 1534201, 1536425, 1536426, 1539656, 1542336, 1543178, 1543189, 1543193
[01:56] <mup> Bug # opened: 1497355, 1508585, 1510951, 1514877, 1534201, 1536425, 1536426, 1539656, 1542336, 1543178, 1543189, 1543193
[01:59] <mup> Bug # changed: 1497355, 1508585, 1510951, 1514877, 1534201, 1536425, 1536426, 1539656, 1542336, 1543178, 1543189, 1543193
[02:02] <mup> Bug #1538868 changed: kill-controller failed: sudo: switch: command not found <ci> <kill-controller> <local-provider> <regression> <juju-core:Invalid> <juju-core api-command-rename:Fix Released by cherylj> <https://launchpad.net/bugs/1538868>
[02:02] <mup> Bug #1541473 changed: ensure-availability brings down the state-server <ci> <ensure-availability> <regression> <tech-debt> <juju-core:Fix Released by cherylj> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
[02:02] <mup> Bug #1543216 changed: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <tech-debt> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1543216>
[02:04] <tych0> cherylj: hrm. still hasn't run :(
[02:04] <tych0> cherylj: is there a queue somewhere i can look at?
[02:08] <mup> Bug #1538868 opened: kill-controller failed: sudo: switch: command not found <ci> <kill-controller> <local-provider> <regression> <juju-core:Invalid> <juju-core api-command-rename:Fix Released by cherylj> <https://launchpad.net/bugs/1538868>
[02:08] <mup> Bug #1541473 opened: ensure-availability brings down the state-server <ci> <ensure-availability> <regression> <tech-debt> <juju-core:Fix Released by cherylj> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
[02:08] <mup> Bug #1543216 opened: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <tech-debt> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1543216>
[02:09] <cherylj> tych0: we've been busy testing master
[02:10] <axw> wallyworld_: sorry, I forgot to look at your branch earlier. it's ready to ship now
[02:10] <cherylj> tych0: now that we're releasing alpha2, CI should pick up other branches
[02:10] <wallyworld_> axw: np, ty. i've been caught up in other things
[02:10] <tych0> cherylj: ah, ok, cool.
[02:11] <cherylj> davecheney: we will probably be doing 1.25.4 after 2.0-beta1.  So, sometime the week of Feb-22
[02:18] <mup> Bug #1538868 changed: kill-controller failed: sudo: switch: command not found <ci> <kill-controller> <local-provider> <regression> <juju-core:Invalid> <juju-core api-command-rename:Fix Released by cherylj> <https://launchpad.net/bugs/1538868>
[02:18] <mup> Bug #1541473 changed: ensure-availability brings down the state-server <ci> <ensure-availability> <regression> <tech-debt> <juju-core:Fix Released by cherylj> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
[02:18] <mup> Bug #1543216 changed: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <tech-debt> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1543216>
[02:19] <anastasiamac> axw: u r all good to go! HUGE thank you for this PR \o/
[02:19] <axw> anastasiamac: thanks, accounts.yaml on its way (basically just a sed command, for real)
[02:19] <axw> anastasiamac: also, your PRs are reviewed
[02:20] <anastasiamac> axw: u r amazing \o/ tyvm!
[02:21] <mup> Bug #1538868 opened: kill-controller failed: sudo: switch: command not found <ci> <kill-controller> <local-provider> <regression> <juju-core:Invalid> <juju-core api-command-rename:Fix Released by cherylj> <https://launchpad.net/bugs/1538868>
[02:21] <mup> Bug #1541473 opened: ensure-availability brings down the state-server <ci> <ensure-availability> <regression> <tech-debt> <juju-core:Fix Released by cherylj> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
[02:21] <mup> Bug #1543216 opened: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <tech-debt> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1543216>
[02:22] <anastasiamac> axw: about show-contoller not showing last model... would be nicer to show all models for this controller with indication of current?
[02:22] <axw> anastasiamac: I think both would be good actually
[02:23] <anastasiamac> axw: excellent \o/ i agree :D
[02:24] <mup> Bug #1538868 changed: kill-controller failed: sudo: switch: command not found <ci> <kill-controller> <local-provider> <regression> <juju-core:Invalid> <juju-core api-command-rename:Fix Released by cherylj> <https://launchpad.net/bugs/1538868>
[02:24] <mup> Bug #1541473 changed: ensure-availability brings down the state-server <ci> <ensure-availability> <regression> <tech-debt> <juju-core:Fix Released by cherylj> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
[02:24] <mup> Bug #1543216 changed: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <tech-debt> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1543216>
[02:26] <axw> wallyworld_: I'll fix your comments in my next branch for accounts
[02:26] <axw> fix/address
[02:26] <wallyworld_> np ata ll
[02:41] <axw> wallyworld_: when you remove the api-info command, can you please remove ModelCommandBase.ConnectionEndpoint (if you haven't already)
[02:41] <wallyworld_> yup
[02:42] <wallyworld_> axw: i'm waiting to merge your work and then will deal with the inevitable conflicts etc
[02:42] <axw> wallyworld_: ok
[02:43] <davecheney> cherylj: ok, i'll work hard to get all my fixes backported before then
[02:46] <anastasiamac> wallyworld_: axw: list-controllers output in spec shows "-" for not-currently-logged-in... AFAIK there is no precedence, can I just leave the column cell empty or is "-" highly desired?
[02:47]  * wallyworld_ checks the spec
[02:48] <anastasiamac> p 9 (of 13)
[02:48] <axw> anastasiamac: I kinda like "-", but prefer consistency
[02:48] <anastasiamac> axw: we can start consistency from here, if it's preferred :D
[02:49] <wallyworld_> "-" is for currently logged in
[02:49] <wallyworld_> not not currently logged in
[02:49] <wallyworld_> right?
[02:49] <wallyworld_> and * is for default
[02:49] <anastasiamac> wallyworld_: USER and MODEL columns
[02:50] <wallyworld_> ah
[02:50] <anastasiamac> wallyworld_: the prefix - is not consistent
[02:50] <anastasiamac> wallyworld_: and list-model uses * suffix to indicate current
[02:50] <wallyworld_> "-" is for the active controller
[02:51] <wallyworld_> you can be logged into more than one
[02:51] <wallyworld_> but only one is active
[02:51] <anastasiamac> wallyworld_: axw and I *thought* *suffix would be nice for active controller too
[02:51] <wallyworld_> how to we denote the default one in that case?
[02:52] <wallyworld_> i agree that  we should be consistent
[02:52] <axw> wallyworld_: we're talking about the "-" in columns that have no value
[02:52] <axw> wallyworld_: separately, there is some inconsistency in the spec w.r.t. using - vs * for active
[02:52] <axw> I think we settled on using * as a suffix
[02:52] <wallyworld_> yes :-(
[02:52] <wallyworld_> ok
[02:53] <anastasiamac> wallyworld_: axw: http://pastebin.ubuntu.com/15013438/
[02:53] <wallyworld_> i must admit, i would like to see "-" for empty region too :-)
[02:54] <wallyworld_> when in doubt, i think we adhere to spec (use "-" for model/user) and ask for feedback
[02:54] <anastasiamac> wallyworld_: yes, I think we should b consistent from now on to show "-" for empty in cmd output :D
[02:55] <anastasiamac> wallyworld_: axw: from the pastebin above, *suffix may be obscured by long names...
[02:55] <axw> wallyworld_ anastasiamac: added AccountStore
[02:55] <axw> https://github.com/juju/juju/pull/4379/
[02:55] <wallyworld_> \o/
[02:55] <anastasiamac> axw: u r powering thru this \o/
[02:55] <axw> anastasiamac: a simple sed command
[02:56] <axw> :)
[02:56] <anastasiamac> axw: all simple things r ingenious :P
[02:57] <mup> Bug # changed: 1382274, 1468972, 1497802, 1511659, 1515289, 1533275, 1533896, 1535165, 1536378, 1537717, 1540701, 1542510
[02:58] <wallyworld_> in your current work, we are moving away from separate current-controller and current-model files right?
[02:58] <anastasiamac> wallyworld_: this is what it looks like form axw's recent PRs \o/
[02:59] <axw> wallyworld_: for now we still have current-controller, but current-model will be no more
[02:59] <wallyworld_> great, i only skimmed, just wanted to check :-)
[02:59] <axw> anastasiamac: ^
[02:59] <axw> we can add current-controller to controllers.yaml too though?
[02:59] <wallyworld_> i think so
[03:00] <mup> Bug # opened: 1382274, 1468972, 1497802, 1511659, 1515289, 1533275, 1533896, 1535165, 1536378, 1537717, 1540701, 1542510
[03:00] <wallyworld_> axw: although, that embeds user state in that file
[03:01] <wallyworld_> so not sure. makes sense for models file as that's a cache
[03:01] <axw> wallyworld_: true. and you'd (probably) never share accounts.yaml.
[03:02] <wallyworld_> yes, i was thinking about accounts.yaml too and think i came to the same conclusion that it's ok to put current account in there, but still am not 100%
[03:02] <wallyworld_> i can see a case for a current-ccount file
[03:02] <axw> wallyworld_: it'll need to be a per-controller file
[03:03] <wallyworld_> true, so in that case, ok as is probably
[03:03] <mup> Bug # changed: 1382274, 1468972, 1497802, 1511659, 1515289, 1533275, 1533896, 1535165, 1536378, 1537717, 1540701, 1542510
[03:04] <anastasiamac> axw: wallyworld_: could we plz update blueprint with all files we are unravelling? :P
[03:04] <wallyworld_> one day
[03:04] <wallyworld_> the files are in the spec
[03:04] <wallyworld_> i don't want to duplicate info
[03:04] <wallyworld_> the blueprint should just refer to the spec
[03:05] <wallyworld_> we should have separate as-built doco
[03:05] <wallyworld_> but that's not for the blueprint, we should have that stuff elsewhere
[03:05] <wallyworld_> we're not good at doing that though :-(
[03:05] <wallyworld_> the blue print can refer to the as-built doc
[03:06] <wallyworld_> the blueprint is more to track progess the way we're using it
[03:06] <anastasiamac> wallyworld_: also to communicate with QA
[03:07] <anastasiamac> wallyworld_: this info can b the backbone of Release Notes
[03:07] <wallyworld_> there needs to be separate doc for that IMO - a proper test plan
[03:07] <anastasiamac> wallyworld_: that we tend to write *after* the effect
[03:07] <wallyworld_> file implementation detail is not for release notes
[03:08] <anastasiamac> wallyworld_: \o/ proper test plan would b amazing!
[03:08] <anastasiamac> when and who would do it?
[03:08] <wallyworld_> all the people we don't have :-(
[03:08] <wallyworld_> should be done as the feature is planned, post one page spec
[03:08] <anastasiamac> file implementation detail is not but what files to expect may b of interest to QA
[03:08] <wallyworld_> sure, but that's not what we are using blueprints for
[03:09] <wallyworld_> the spec in this case has the file detail
[03:09] <wallyworld_> but it's not detailed enough for QA - we need a test plan
[03:10] <wallyworld_> wish there were more hours in a day
[03:10] <anastasiamac> wallyworld_: i agree, jeez, a lot of planning and definition needs to happen after one pager :D Test Plans, Acceptance Criteria, Task break down
[03:10] <wallyworld_> indeed
[03:10] <wallyworld_> we do the task breakdown
[03:10] <anastasiamac> wish we had a dedicated resource... :)))
[03:10] <wallyworld_> yes :-(
[03:11] <anastasiamac> wallyworld_: https://www.youtube.com/watch?v=Dj3GH5myc3M
[03:11] <wallyworld_> rotflmao
[03:12] <wallyworld_> you look nothing like a donkey
[03:12] <wallyworld_> are you saying i am an ogre
[03:13] <anastasiamac> wallyworld_: not everything needs to be read literally (just btw the lines) :P
[03:13] <wallyworld_> i know, just going along with the theme
[03:13] <anastasiamac> :)) i know u know
[03:17] <axw> wallyworld_: a smaller, easier one: http://reviews.vapour.ws/r/3823/
[03:17] <wallyworld_> looking
[03:17] <axw> so we don't need to change crap that can just be deleted
[03:18] <wallyworld_> +1 to that
[03:18] <anastasiamac> +2
[03:20] <wallyworld_> axw: there may be some nuggets in api_test that need to be retain i suspect?
[03:20] <wallyworld_> or at least re-homed
[03:21] <axw> wallyworld_: the file's not gone, the branch is conflicted so it doesn't show up on RB
[03:21] <axw> wallyworld_: will fix in a sec, look on GitHub in the mean time please
[03:21] <wallyworld_> ok
[03:35] <axw> wallyworld_: so once controllers, models, accounts are all in, what else are you waiting on?
[03:35] <axw> wallyworld_: are you doing the changes to pass controller/model name through, or am I?
[03:35] <axw> pass through to API conn opening code that is
[03:36] <wallyworld_> i was working to eliminate cache.yaml
[03:36] <wallyworld_> remove bootstrap config etc
[03:36] <wallyworld_> and not write controller addresses, accounts etc
[03:36] <wallyworld_> you could do the work to pass in controller/model first
[03:37] <wallyworld_> i am currently adding private-key to joyent
[03:37]  * thumper headdesks
[03:37] <wallyworld_> but the credentials stuff needs to pass in the optional attr
[03:37] <axw> wallyworld_: seems like something you'd do at the same time
[03:37] <wallyworld_> ok, np, i can do do, need to look at the code again
[03:37] <axw> wallyworld_: that's why I don't want it to be a separate attr, but a flag on the attr that allows you to specify a file
[03:38] <axw> wallyworld_: I'm happy to do it, just not sure how far into it you are
[03:38] <wallyworld_> the joyent stuff?
[03:38] <wallyworld_> just started looking
[03:38] <wallyworld_> so you can do that if you want
[03:38] <axw> wallyworld_: no, the API stuff
[03:39] <wallyworld_> i have a branch that i started that has a shit tonne of changes, but many will be conflicting with your recent work; i think it just needs to be discarded
[03:39] <wallyworld_> so you could look to do that next bit while you're on a roll in the area
[03:41] <axw> wallyworld_: ok. if I can, I'll leave stuff to be done in parallel
[03:41] <wallyworld_> axw: what i can do first if you want is remove the bootstrap config stuff
[03:41] <wallyworld_> that won't conflict too much
[03:41] <axw> wallyworld_: that would be good
[03:42] <wallyworld_> axw: in the interim, did you want to add that fromfile attr to credentials schema? CI needs it
[03:42] <wallyworld_> as they like to use the private-key directly
[03:42] <axw> wallyworld_: ok, I'll take a lok
[03:42] <axw> look*
[03:42] <wallyworld_> ok, ty
[03:45] <wallyworld_> axw: damn, such a long queue waiting to land, hopefully your account store is not at the end
[03:46] <axw> wallyworld_: maybe just pull my branch down and work off that?
[03:46] <axw> wallyworld_: actually you shouldn't need it
[03:46] <axw> if you're just removing bootstrap bits
[03:47] <wallyworld_> might go a bit further depending. wil grab a bite to eat
[03:50] <anastasiamac>  /me is surprised thumper's desk is still standing
[04:02] <davecheney> thumper: PTAL
[04:02] <davecheney> https://github.com/juju/juju/pull/4361
[04:02] <davecheney> totally redone and made much simpler
[04:03] <davecheney> no reviewboard link im afraid
[04:08] <thumper> hmm... I wonder why no reviewboard
[04:14] <davecheney> 'cos I closed the old review
[04:14] <davecheney> removed the link from the description
[04:14] <davecheney> but rb didn't add a new one
[04:33] <davecheney> bootstrapping
[04:33] <davecheney> is
[04:33] <davecheney> soooo
[04:33] <davecheney> slow
[04:33]  * davecheney drums fingers while some huge file is uuencoded, sent to the remote bash at a few kb / sec
[04:37] <davecheney> thumper: if this bootstrap works
[04:37] <davecheney> are you find with me to JFDI this fix onto master
[04:37] <davecheney> then I'll roll up a big backport patch for 1.25
[04:37] <thumper> which fix is this?
[04:37] <thumper> the error stuff?
[04:38] <davecheney> https://github.com/juju/juju/pull/4361
[04:38] <davecheney> this is all the groudnwork I think we need to implement retrying on all API requests
[04:42] <thumper> davecheney: yes
[04:45] <wallyworld_> axw: the preferIPv6 flag is used to sort the host api addresses so that ipv6 appear first because we start at the top of the list and try each in turn
[04:45]  * thumper is off now
[04:45] <axw> wallyworld_: I understand how, but not why
[04:46] <axw> wallyworld_: if we're trying them all, why does it matter...?
[04:46] <wallyworld_> because we will take the first one we connect to i think
[04:47] <wallyworld_> connect to successfully
[04:48] <axw> wallyworld_: yep... why does that matter? :)
[04:49] <wallyworld_> not sure, but i assume this has come from stakeholders who want juju to connect to ipv6 if at all possible
[04:49] <axw> wallyworld_: I *think* it might be because api-endpoints prints out the last-connected-to address,  and someone was relying on that being v4/v6
[04:49] <wallyworld_> yeah, not sure either
[05:37] <axw> wallyworld_: no rush, but joyent change is here: http://reviews.vapour.ws/r/3827/
[05:37] <axw> wallyworld_: not tested because I have no account, but there's a unit test un the cloud package
[05:38] <wallyworld_> axw: awesome, ty. have almost finished unpicking the change from my conflicted branch that i want to keep, have tests to fix. btw you can get joyent creds from cloud-city repo
[05:38] <wallyworld_> changes
[05:38] <axw> wallyworld_: cool
[05:39] <axw> wallyworld_: yeah, being lazy. I'm pretty sure it's ok.
[05:48] <wallyworld_> axw: lgtm
[05:49] <axw> wallyworld_: ta
[05:49] <axw> wallyworld_: it's a bit more than immediately necessary, but my intention is to add things like this into environschema
[05:49] <wallyworld_> yep, i like it
[05:51] <wallyworld_> fark so many failing tests to fix :-( i hate tests that compare log lines
[05:52] <wallyworld_> axw: remind me - restore will be broken with the current cloud-credentials branch i think you said?
[05:52] <axw> wallyworld_: correct
[05:53] <wallyworld_> axw: we'll need to fix that if we want to get this branch into master for beta1. is that something you could look at next rather than the next round of feature work
[05:54] <axw> wallyworld_: ok
[05:54] <wallyworld_> ta, i can't recall the scope of the problem offhand
[05:54] <wallyworld_> hopefully not too major
[05:55] <axw> wallyworld_: https://github.com/juju/juju/blob/cloud-credentials/cmd/juju/backups/restore.go#L133
[05:55] <wallyworld_> ah yes that's right
[05:57] <axw> wallyworld_: I'm assigning 5 points to that, sound reasonable?
[05:58] <wallyworld_> think so, or 8 if it turn ulgy
[05:59] <wallyworld_> axw: as a drive by, could you also change the version to "delta1" so that the QA guys can target the new scripts
[06:00] <axw> wallyworld_: delta? not beta?
[06:00] <wallyworld_> axw: master is beta1, we need something different for this feature branch just as the new scripts are being tested
[06:00] <axw> wallyworld_: ok
[06:00] <wallyworld_> we will change back to beta1 prior to merge
[06:51] <davecheney> wat?
[06:51] <davecheney>         "github.com/juju/juju/apiserver/testing"
[06:51] <davecheney>         apiservertesting "github.com/juju/juju/apiserver/testing"
[06:54] <dimitern> :) my fav so far is "gitjujutesting"
[07:54] <davecheney> why do we have juju/api, the client
[07:54] <davecheney> and
[07:54] <davecheney> juju/apiserver/client ... ?
[08:07] <axw> wallyworld_: the restore-rebootstrap code is broken in general. I propose we delete it.
[08:08] <axw> wallyworld_: ... and just require people to bootstrap-then-restore
[08:09] <axw> wallyworld_: (BTW, CI is not using this code path AFAICS)
[09:10] <frobware> dimitern, voidspace, dooferlad: I'm back in the land of the living \o/
[09:11] <frobware> dimitern, voidspace, dooferlad: and this (http://reports.vapour.ws/releases/3596) tells me maas-spaces is blessed. \o/ \o/ \o/
[09:11] <frobware> dimitern, voidspace, dooferlad: nice work!
[09:14] <voidspace> frobware: double yay!
[09:14] <voidspace> \o/
[09:19] <dimitern> frobware, hey! welcome back! :)
[09:19] <dimitern> frobware, oh yeah! we're merging today
[09:43] <jamespage> dimitern, frobware: some comments on the extra bindings stuff but I think it will fulfill our requirements
[09:43] <dimitern> jamespage, awesome! tyvm
[09:44] <frobware> jamespage, thanks. I think your "is this a list" can be answered by the "Future extensions" section
[09:44] <jamespage> frobware, ack - i see
[09:44] <dimitern> frobware, you can't hear me apparently
[09:44] <frobware> jamespage, I was just typing that when your ^ message arrived. :)
[09:44] <jamespage> one comment on the network-get use for extra-bindings - feels odd with just the name but that might be just me
[09:44] <frobware> dimitern, nope. problem is definitely at my end.
[09:45] <dimitern> frobware, I can hear you fine though
[09:47] <TheMue> morning folks o/
[09:55] <voidspace> TheMue: o/
[09:55] <voidspace> dimitern: so, I'm building a function that builds a map of spaces from maas name -> SpaceInfo
[09:56] <voidspace> dimitern: we *could* use that in maasEnviron.Spaces to set ProviderId as well as Name
[09:56] <voidspace> dimitern: shall I do that in my branch or leave it for a follow up?
[09:57] <voidspace> dimitern: (we still need the space name from MAAS here so we can generate a juju name)
[09:59] <dimitern> voidspace, let's chat during standup
[09:59] <voidspace> dimitern: kk
[11:07] <dimitern> frobware, fyi, here's how I tested: http://paste.ubuntu.com/15015446/
[11:10] <frobware> dimitern, do you currently see any failures with what's on maas-spaces now?
[11:11] <dimitern> frobware, yes, that's the base line - about 10 out of 50, the one with the patch is running now
[11:11] <frobware> dimitern, can you pastebin the patch
[11:12] <dimitern> frobware, http://paste.ubuntu.com/15015467/
[11:12] <dimitern> voidspace, ^^ that's what you meant, right?
[11:12] <frobware> dimitern, ty
[11:14] <dimitern> frobware, with the patch I can see the forked processes running almost in sync
[11:15] <frobware> dimitern, and which version of Go are you using?
[11:16] <dimitern> frobware, on first glance - fewer failures: 7 out of 50, but in reality less than 5 due to TestLoginsDuringUpgrade - the rest are mongo panics and other similar
[11:17] <dimitern> frobware, go version go1.6rc2 linux/amd64
[11:19] <frobware> dimitern, so I initially tried with loop(1..5). I got one failure. What's the failure message to look for without the patch?
[11:19] <frobware> dimitern, upgradeSuite.TestLoginsDuringUpgrade?
[11:21] <dimitern> frobware, usually upgrade_test.go:316:
[11:23] <dimitern> frobware, actually with the patch it's always that same line - without it occasionally lines 138 or 129 fail as well
[11:24] <frobware> dimitern, so it fails with the patch too?
[11:25] <dimitern> frobware, it does, but about less than half of the unpatched runs
[11:26] <dimitern> s/of/compared to
[11:26] <frobware> dimitern, so not a slam dunk in terms of landing this before merging maas-spaces back into master...
[11:27] <frobware> dimitern, just trying to assess the risk of landing this change vis-a-vis merging what we have
[11:27] <dimitern> frobware, I still think landing as is ok atm
[12:08] <wallyworld_> axw: sounds ok to me, sorry i was at soccer. if it didn't work anyway, then no point keeping it
[12:21] <voidspace> dimitern: not really
[12:21] <voidspace> dimitern: just the changes lines 28-29 in that diff are sufficient
[12:21] <voidspace> dimitern: the other changes are fine too I guess
[12:24] <dimitern> voidspace, cheers
[12:25]  * dimitern just realized we haven't tried maas-spaces on maas 1.10 - yet another maas to setup (mostly done anyway)
[12:33] <frobware> dimitern, voidspace, dooferlad: I plan to postpone the release note sync. any objections?
[12:33] <dimitern> frobware, +1
[12:40] <voidspace> cool
[13:09] <voidspace> dimitern: heh, so the spaces endpoint isn't implemented in the gomaasapi test server
[13:09] <voidspace> dimitern: so looks like I'm diverting into that
[13:12] <dimitern> voidspace, yeah, unfortunately, but it can be worked around
[13:12] <dimitern> voidspace, like what I did for the interfaces
[13:12] <voidspace> dimitern: well, I can patch out the function - but then that code isn't tested
[13:13] <dimitern> voidspace, the parsing can be tested given a maasObject
[13:13] <voidspace> dimitern: well yes, but it still leaves untested code
[13:13] <dimitern> voidspace, but at this point it's better to do it properly and start tackling the piling gomaasapi changes we need
[13:14] <voidspace> dimitern: so you're saying I should implement spaces for gomaasapi?
[13:14] <voidspace> it's not hard
[13:14] <dimitern> voidspace, yeah, exactly
[13:14] <voidspace> dimitern: cool
[13:21] <frobware> dimitern, so I tested a bit, with/without the patch and looping(1..5) - failure rate seems identical.
[13:21] <frobware> voidspace, ^^
[13:22] <voidspace> frobware: dimitern: The change is still good, but may not be the root issue for this test.
[13:22] <frobware> voidspace, yeah, we should separate the two. patch good, but there's something else too.
[13:22] <voidspace> frobware: dimitern: I haven't had a chance to look at the test, but I suspect if it's just trying to login after upgrade and it hits a discovery in progress error it need to try again (in a short attempt loop)
[13:25] <voidspace> frobware: hmm, it's in a LongAttemptLoop
[13:25] <voidspace> frobware: what's the full failure message please
[13:26] <frobware> voidspace, bear with - I'll pastebin a failure.
[13:26] <voidspace> frobware: ah, during discovery api.Open will fail - so line 316 should be "return err" not an Assert
[13:26] <voidspace> dimitern: ^^
[13:27] <voidspace> dimitern: that should fix it
[13:28] <dimitern> voidspace, hmm possibly, yeah
[13:29] <voidspace> dimitern: I'm pretty sure  - I hit that in writing the code/tests for limitLogins
[13:29] <voidspace> because we're preventing login, not returning a restricted api
[13:30] <voidspace> you should see very similar code in the machine_test.go for limited logins during space discovery
[13:30] <voidspace> api.Open returns an error until discovery is completed
[13:31] <voidspace> and it's intermittent because it's timing related - there's only an error if the login attempt is in the short window whilst discovery is in progress
[13:33] <dimitern> voidspace, sounds good
[13:33] <dimitern> voidspace, and we do have another test to check that client logins are blocked while agent logins are not?
[13:35] <voidspace> dimitern: yes
[13:35] <voidspace> dimitern: the test tries to login as a user - that fails with the right error message
[13:35] <voidspace> dimitern: then it checks it *can* login as the local machine and that succeeds
[13:35] <voidspace> dimitern: then after discovery completes the client login succeeds
[13:36] <dimitern> voidspace, sweet!
[13:38] <frobware> voidspace, http://pastebin.ubuntu.com/15016031/
[13:40] <voidspace> frobware: in featuretest/upgrade_test.go change line 316 from c.Assert to "if err != nil { return err}"
[13:40] <voidspace> frobware: it *should* pass more reliably then
[13:41] <voidspace> the real commit should have a comment too I guess that api.Open can fail if discovery is still in progress
[13:41] <voidspace> and it should be *with* dimitern's fix to prevent deadlock
[13:41] <frobware> voidspace, ok - funnily enough I just got 3 successful runs ... hence why it took a while to pastebin. :)
[13:54] <frobware> voidspace, oh-la-la. I'm now out of disk space, so the tests are failing... Grrr.
[13:55] <frobware> voidspace, looks like mongo is leaving stuff in /tmp. Approximately 5GBs worth. :(
[13:55] <voidspace> nice
[13:58]  * voidspace lunch
[13:58] <frobware> voidspace, I need to go eat too. bbiab.
[14:59] <dimitern> frobware, dooferlad, voidspace, guys, I've prepared the merge PR: https://github.com/juju/juju/pull/4392 and I'll leave you to your judgment, but now's the best time to get it in
[15:00]  * dimitern goes to get some rest (off tomorrow btw)
[15:02] <katco> ericsnow: standup time
[15:32] <voidspace> frobware: I say ShipIt
[15:32] <frobware> voidspace, sure? ;)
[15:32] <frobware> voidspace, the err check instead of assert makes a diff.
[15:34] <voidspace> frobware: does?
[15:35] <voidspace> cherylj: ping
[15:35] <frobware> voidspace, yes. just double-checking because the tests leave /tmp/test-mgo* files around so can't run it for a long time. Just working around that atm.
[15:35] <voidspace> frobware: cool
[15:35] <voidspace> frobware: I can do that on master with the potential deadlock fix
[15:35] <voidspace> after maas-spaces lands
[15:36] <frobware> voidspace, agreed. but give me 20 mins, as I'm part way through this already.
[15:36] <voidspace> frobware: it will take that long to land maas-spaces anyway I think, waiting on cherylj to give the ndo
[15:36] <frobware> voidspace, btw, we just got a maas-spaces cursed build.
[15:36] <voidspace> *nod even
[15:38] <frobware> cherylj, we have a both a blessed and cursed maas-spaces build. Choose your poison. :)
[15:38] <voidspace> cherylj:  frobware: leadership (uniter) tests failed in attempt 291 but succeeded in 292
[15:38] <voidspace> (trusty unit tests)
[15:39] <voidspace> that was the only failure
[15:49] <alexisb> frobware, cherylj are we need a CI on MAAS Spaces?
[15:49] <voidspace> alexisb: we had a bless
[15:49] <frobware> alexisb, we've had two results today. 1 blessed, and just recently 1 cursed.
[15:49] <voidspace> alexisb: then a curse due to a flakey test
[15:49] <alexisb> SWEET!
[15:49] <frobware> :)
[15:50] <frobware> alexisb, personally, I'm big fan of the first result.
[15:50] <alexisb> cherylj, sinzui are there any high priority branches we are needed to test asap?
[15:50] <alexisb> frobware, heh
[15:50] <sinzui> alexisb: upgrade-mongodb3
[15:50] <alexisb> sinzui, past that run can we queue up lxd-container-type for tych0 ?
[15:50] <sinzui> alexisb: we are retesting maas-spaces which had i386 and ppc64el failures.
[15:51] <sinzui> alexisb: oh, well, it is actually in the priority list after mongo3
[15:51] <alexisb> sweet, thanks
[15:52] <frobware> alexisb, sinzui: am I hearing we're waiting for another blessed build?
[15:52] <sinzui> frobware: yes.
[15:53] <frobware> boo said the crowd
[15:53] <frobware> sinzui, is this some form of majority vote?
[15:55] <sinzui> frobware: no. there are voters and non-voters. ppc64el unit tests vote. Ci will willing to test 3 times...juju is that bad on ppc64el. But maas-spaces might need 5 or 6 tries to pass
[15:56] <frobware> sinzui, I meant in terms of status overall. this morning maas-spaces was blessed.
[15:56] <dooferlad> voidspace: can I pick your brains for a moment?
[15:57] <voidspace> dooferlad: sure
[15:58] <sinzui> frobware: yes, but dimitern merged another change and now we don't have a bless. also. I forced a retest of ppc as you were waking up to get that bless
[15:58] <dooferlad> voidspace: hangout?
[15:58] <voidspace> dooferlad: sure
[15:58] <voidspace> dooferlad: give me ten minutes!
[15:58] <voidspace> dooferlad: send me a hangout link - just about to phone the bank
[15:59] <dooferlad> voidspace: no problem. Ping me when you are ready. Was going to use https://plus.google.com/hangouts/_/canonical.com/juju-sapphire?authuser=0
[15:59] <frobware> sinzui, which change? this one? http://reviews.vapour.ws/r/3829/
[16:01] <sinzui> maybe http://reports.vapour.ws/releases/3597 points to https://github.com/juju/juju/commit/f4de48d033ce30be495756492ba3ab726a3ec68f
[16:01] <sinzui> frobware: I am going to restart the host and retest
[16:01] <frobware> sinzui, ack
[16:08] <frobware> sinzui, is ppc64 using gc or gccgo?
[16:09] <sinzui> frobware: gccgo-go
[16:09] <frobware> sinzui, ok I temporarily have access to h/w - will try running the unit tests.
[16:09] <sinzui> frobware: you have permanent access to the stilsons CI uses.
[16:10] <voidspace> dooferlad: frobware: alexisb: my daughter just had a fit (febrile convulsion - she's had them before)
[16:10] <frobware> sinzui, heh. yes, I keep forgetting about that...
[16:10] <voidspace> dooferlad: frobware: alexisb: need to sign out for a bit
[16:10] <sinzui> frobware: you have access to every CI host you need to do you job.
[16:10] <voidspace> alexisb: I'll probably miss our meeting tonight :-(
[16:10] <alexisb> voidspace, take the time you need
[16:10] <voidspace> just called for ambulance
[16:10] <alexisb> not a problem
[16:10] <dooferlad> voidspace: sure.
[16:10] <alexisb> my thoughts are with you guys
[16:13] <frobware> sinzui, so... what can I do on those machines? clone my juju repo, build, et al?
[16:16] <sinzui> frobware: those machines are on canonical's network. they are very restricted. I scp files up and run them on the host.
[16:16] <natefinch> good luck voidspace
[16:25] <frobware> sinzui, and cross-compile from x86?
[16:29] <sinzui> frobware: no cross-compile. the compiler on ppc64el is not the compiler you have on amd64. We do everythign native. debs are created on the ppc. in the case of the unit-tests. we make a release tarfile, untar it on the host and run the unit-tests. the host has go ready or it can be installed. I think we need to use stilson-07 now because 08 is dedicated to go1.5 testing
[16:29] <frobware> sinzui, ok. on the h/w I'm using I was using gcc-go-4.9
[16:30] <sinzui> go version
[16:30] <sinzui> go version xgcc (Ubuntu 4.9.3-0ubuntu4) 4.9.3 linux/ppc64le
[16:32] <voidspace> natefinch: thanks
[16:32] <frobware> sinzui, I have:
[16:32] <frobware> go version go1.4.2 gccgo (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010 linux/ppc64le
[16:32] <voidspace> frobware: alexisb: dooferlad: she's ok, she has these fits when she gets a high temperature (inherited from her mother unfortunately)
[16:33] <frobware> voidspace, all resolved? hope so...
[16:33] <voidspace> frobware: alexisb: dooferlad: but I have to go to hospital with her now (they always take her in after them)
[16:33] <voidspace> frobware: she's fine, she won't stay overnight
[16:33] <voidspace> but I have to go :-(
[16:33] <natefinch> voidspace: go go!
[16:33] <frobware> voidspace, sure
[16:33] <alexisb> voidspace, I am glad it sounds like she is ok, take care
[16:41] <frobware> sinzui, are the CI machines running wily?
[16:41] <frobware> sinzui, for ppc64
[16:41] <sinzui> frobware: trusty except for one wily that is not running any unit tests
[16:42] <frobware> sinzui, ok, I suspect that explains the gcc go version difference.
[16:54] <perrito666> Bbl lunch
[17:25] <mup> Bug #1544662 opened: cannot bootstrap with mongodb3 and manual-provider <bootstrap> <manual-provider> <mongodb> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544662>
[17:28] <mup> Bug #1544662 changed: cannot bootstrap with mongodb3 and manual-provider <bootstrap> <manual-provider> <mongodb> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544662>
[17:31] <mup> Bug #1544662 opened: cannot bootstrap with mongodb3 and manual-provider <bootstrap> <manual-provider> <mongodb> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544662>
[17:35] <mup> Bug #1544662 changed: cannot bootstrap with mongodb3 and manual-provider <bootstrap> <manual-provider> <mongodb> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544662>
[17:36] <benji> goo/quit
[17:41] <mup> Bug #1544662 opened: cannot bootstrap with mongodb3 and manual-provider <bootstrap> <manual-provider> <mongodb> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544662>
[17:56] <mup> Bug #1526063 changed: TestNoContextWithLock <ci> <intermittent-failure> <test-failure> <juju-core:Invalid> <juju-core maas-spaces:Fix Released> <https://launchpad.net/bugs/1526063>
[18:32] <mup> Bug #1544694 opened: [maas-provider] Juju is incorrectly  configuring os bridge interfaces <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1544694>
[18:41] <natefinch> man, our pseudo transactions make separating the business logic from the persistence layer nearly impossible.
[18:50] <natefinch> ericsnow: did you have ideas on how to increment the CharmModifiedVersion in the same transaction as SetResource?  I can do it the horrible hacky way, where resource persistence now has intimate knowledge of the service collection's info... not sure what my other options are, besides not having them in the same transaction, which seems very likely to cause bugs if something only half-succeeds.
[18:52] <ericsnow> natefinch: gah, yet again mongo transactions are making us leak persistence info into state :(
[18:52] <ericsnow> natefinch: I do have a plan
[18:53] <natefinch> ericsnow: yeah, I hate that about our transactions....
[18:57] <ericsnow> natefinch: consider adding a "NewServiceCharmModifiedOps()" method to resource/persistence.PersistenceBase
[18:57] <ericsnow> natefinch: then the adapter in component/all/resource.go must provide that, exposing a similarly named helper in corestate
[18:58] <ericsnow> natefinch: or just in state/resources.go, since that is the point of that file :)
[18:59] <ericsnow> natefinch: (the point: avoid exporting more persistence concerns out of the state package)
[18:59] <natefinch> ericsnow: ahh, yeah, ok.  I was trying to figure out how to get the left hand to talk to the right hand.  I was looking at state/resources.go and trying to figure out how to do it there.  Iget it.
[18:59] <ericsnow> natefinch: cool
[19:00] <ericsnow> natefinch: let me know if you get stuck on that or have any other questions
[19:01] <katco> ericsnow: natefinch: merge of master into the feature-branch just succeeded. may want to rebase
[19:01] <ericsnow> katco: nice!
[19:01] <natefinch> katco: huzzah!
[19:01] <natefinch> katco: thanks so much for taking that on.
[19:01] <katco> natefinch: happy to so you guys can keep kickin arse :)
[19:02] <ericsnow> natefinch, katco: +1
[19:02] <katco> ericsnow: natefinch: cherylj: we should see if we can get a CI run through by tomorrow so we can merge INTO master
[19:02] <cherylj> katco: well, we're trying to merge maas-spaces now, so there will be one less branch to compete with for CI runs :)
[19:03] <katco> cherylj: :) is there any way to guarantee a run?
[19:03] <cherylj> let me send you my paypal link
[19:03] <cherylj> ;)
[19:03] <natefinch> lol
[19:04] <katco> cherylj: oh man if i had known this is how this works...
[19:04] <cherylj> we were mostly focusing on master until we got the bless yesterday.
[19:04] <cherylj> mongo3 was up next, then lxd-container-type, then I think your branch
[19:05] <mup> Bug #1544694 changed: [maas-provider] Juju is incorrectly  configuring os bridge interfaces <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1544694>
[19:06] <natefinch> katco, cherylj, alexisb: team meeting?  Or should we skip it?
[19:07] <katco> cherylj: sweet! is there somewhere i can view the queue?
[19:07] <katco> natefinch: in another meeting atm, so i can't attend
[19:28] <cherylj> MAAS SPACES HAS MERGED
[19:28] <cherylj> I repeat
[19:28] <cherylj> MAAS SPACES HAS MERGED!!!
[19:29] <cherylj> alexisb, frobware ^^
[19:29] <alexisb> :)
[19:30]  * natefinch gets the feeling from the all caps, that this is a big deal.
[19:30] <cherylj> YES IT IS
[19:30] <cherylj> heh
[19:30]  * lazyPower throws confetti
[19:30] <lazyPower> natefinch i have to confetti if you have fanfare under control :D
[19:31] <lazyPower> so/to/the/
[19:35] <katco> cherylj: woo! grats to everyone
[19:35]  * katco has a sinking feeling that she had better merge master again
[19:36] <cherylj> katco: yes :)
[19:36]  * katco cries into her coffee
[19:37] <katco> 9 conflicts. here we go again.
[19:41] <lazyPower> heyyyy cherylj
[19:42] <lazyPower> does juju 2.0 alpha bidniss work with maas 1.8? or do i need to upgrade to 1.9?
[19:44] <alexisb> lazyPower, you will need to upgrade to 1.9
[19:45] <lazyPower> ah, well that explains the weird issue i'm seeing about series mismatches
[19:45]  * lazyPower grabs a pick and returns to the maas saltmines
[19:58] <natefinch> ericsnow: am I correct in assuming that a staged resource that is being activated will never be pending?
[19:59]  * ericsnow thinks about it
[20:05] <ericsnow> natefinch: pending resources should be staged as well, for exactly the same reason we stage non-pending resources
[20:06] <ericsnow> natefinch: however, I think the staging code isn't doing it right (there's a slight race)
[20:09] <ericsnow> natefinch: in resource/persistence/mongo.go, stagedID() should accommodate pending IDs
[20:10] <ericsnow> natefinch: that isn't a problem now, but could be in the future
[20:19] <katco> ericsnow: hey can you hop into moonstone?
[20:43]  * frobware looks through the scrollback and HEADS TO THE BAR! :-D
[20:47]  * frobware ponders... maas-spaces has landed. Gravitational waves breakthrough. Surely just a coincidence.
[20:59] <mup> Bug #1544724 opened: repeatedly checks /dev/fd0 when it doesnt even exist <juju-core:New> <https://launchpad.net/bugs/1544724>
[21:02] <perrito666> well, that was something from the past
[21:02] <mup> Bug #1544724 changed: repeatedly checks /dev/fd0 when it doesnt even exist <juju-core:New> <https://launchpad.net/bugs/1544724>
[21:02] <katco> frobware: you need to keep these jokes coming.
[21:14] <mup> Bug #1544724 opened: repeatedly checks /dev/fd0 when it doesnt even exist <juju-core:New> <https://launchpad.net/bugs/1544724>
[21:24] <natefinch> man, I am terrible at bash
[21:24] <perrito666> natefinch: good that ensures you are not going around embedding bash in go
[21:28] <natefinch> ericsnow: btw, I think there's a bug in how we load resource information... when you deploy a local charm, the resource info defaults to says it's a charmstore resource, which is not correct
[21:29] <ericsnow> natefinch: yep
[21:39] <natefinch> ahh man, the uniter tests are so slow.....
[21:42] <natefinch> sigh... that feeling when I forget to filter out all the logging, so I can't even tell what failed...
[21:43] <natefinch> OMG these tests are so bad
[21:56] <thumper> fwereade: ping?
[21:58] <tych0> sinzui: alexisb: ok. i think i've updated. i basically just merged master and cherry picked a bunch of old commits on top because git didn't figure it out. i'd prefer a rebase, but it's not obvious to me how to accomplish that with juju's feature branch setup. https://github.com/juju/juju/pull/4396 is the PR
[22:09] <katco> ericsnow: can you please review natefinch-afk 's branch so we can possibly land that tonight before the ci run?
[22:09] <ericsnow> katco: sure
[22:10] <katco> ericsnow: ty... i'll try and weigh in if i can get this merge through, but feel free to give it a ship it w/o me
[22:15] <alexisb> tycho, you can just merge the rebase into your feature branch
[22:16] <alexisb> once it is merged we can just re-queue for CI
[22:17] <katco> tych0: generally you don't need a review for merging master into your feature branch
[22:17] <katco> tych0: rebases are nice, but rebasing a feature branch on top of master is a headache, so most people just merge master in
[22:17] <tych0> ok. so nobody will be offended if i $$merge$$ myself?
[22:17] <katco> tych0: nope, not if it's a feature branch
[22:17] <tych0> ok.
[22:17] <katco> tych0: and it's just a merge from master
[22:17] <tych0> well, it's a merge from master + some fixups
[22:18] <tych0> which are mostly just cherry-picks of previously reviewed commits because git sucks :)
[22:18] <katco> tych0: were the fixups reviewed at one point?
[22:18] <katco> tych0: yeah, you're fine :)
[22:18] <tych0> katco: cool, thanks.
[22:18] <katco> tych0: maybe do those in a separate pr next time, but not a huge deal
[22:18]  * katco is currently merging from master as well
[22:18] <tych0> well, i can't because the resulting merge won't build without them
[22:18] <katco> ah i see
[22:44] <menn0> thumper: "juju migrate" is here: http://reviews.vapour.ws/r/3839/
[22:56] <katco> ericsnow: natefinch-afk: merge from master just landed
[22:56] <ericsnow> katco: k, thanks!
[22:59] <katco> ericsnow: natefinch-afk: we're also last in the queue to get a ci bless, so have a bit of time to land patches.
[23:35] <tych0> looks like my merge failed, but i'm not entirely convinced the errors are mine: http://juju-ci.vapour.ws:8080/job/github-merge-juju/6362/console
[23:35] <tych0> katco: cherylj: thoughts? ^
[23:35] <cherylj> looking
[23:36] <cherylj> ah, the dreaded bad record MAC
[23:36] <cherylj> just retry the $$merge$$
[23:36] <davecheney> cherylj: was there a successful CI run last night ?
[23:36] <cherylj> davecheney: yes, we got a bless on master
[23:36] <davecheney> i want to make sure the logging and rpc changes I have made so far are blessed before I backport them to 1.25
[23:36] <davecheney> excellent, excellent, chrry-pick coming right up
[23:37] <cherylj> tych0: yeah, looks like the bad record MAC was the only problem, just retry the $$merge$$
[23:37] <davecheney> just the uusual mongodb is web scale problem
[23:37] <davecheney> ignore it
[23:38] <tych0> ok :)
[23:40] <davecheney> oh my god
[23:41] <davecheney> why is the apiserver code base like an episde of hoarders
[23:41] <davecheney> it's got every line of code ever written in thre
[23:41] <davecheney> nothing is every thrown away
[23:41] <davecheney> even the apiserver has a client, even though there is another client in another package
[23:41] <davecheney> this is like buying one of every color in the store so they don't feel lonely