| menn0 | thumper: next one (small): http://reviews.vapour.ws/r/5112/ | 00:17 |
|---|---|---|
| davechen1y | menn0: re: the conversation we had at standup | 00:21 |
| wallyworld | redir: sorry, network dropped | 00:29 |
| davechen1y | menn0: increasing the timeout, i'm having trouble finding the place to make that change | 00:30 |
| redir | wallyworld: meeting timeout:) | 00:31 |
| wallyworld | redir: yeah, sorry, network dropped out | 00:32 |
| wallyworld | i think we had finished? | 00:32 |
| redir | sure | 00:32 |
| redir | I've got enough rope... | 00:32 |
| menn0 | davechen1y: I was thinking that testWatcher.NumDeltas should be changed to take a timeout | 00:41 |
| menn0 | davechen1y: and then change the 2 calls to it so that AssertNoChanges passes ShortWait and AssertChanges passes LongWait | 00:41 |
| davechen1y | There are millions of AssertNoChanges | 00:41 |
| davechen1y | and something about a stringsWatcher | 00:42 |
| menn0 | davechen1y: the 2 places where NumDeltas is called | 00:42 |
| davechen1y | is that a test mock ? or the usual strings watcher | 00:42 |
| davechen1y | oh creap | 00:42 |
| davechen1y | https://bugs.launchpad.net/juju-core/+bug/1594578 | 00:42 |
| menn0 | testWatcher.AssertNoChange and | 00:42 |
| mup | Bug #1594578: state: test failure in race build <juju-core:New> <https://launchpad.net/bugs/1594578> | 00:42 |
| davechen1y | I was looking at the wrong bug | 00:42 |
| davechen1y | sorry, it should make sense now | 00:42 |
| menn0 | davechen1y: looks to be a special mock/fake for these tests | 00:43 |
| menn0 | it's all a bit ropey | 00:43 |
| menn0 | davechen1y: the whole NumDeltas thing a bit crap... maybe there's a better way. | 00:44 |
| wallyworld | thumper: does maas 1.9 support arbitary tags on machines? maas 2 does right - that tag slice on gomaasapi/machine can have anything added to it we want during StartInstance() ? | 01:11 |
| thumper | wallyworld: no | 01:11 |
| thumper | the tag slice at the moment is maas tags | 01:11 |
| thumper | not user defined tags | 01:11 |
| thumper | I don't think gomaasapi exposes the user tags yet | 01:11 |
| wallyworld | damn ok | 01:12 |
| wallyworld | was hoping to add controller uui etc | 01:12 |
| thumper | nope | 01:12 |
| thumper | sorry | 01:12 |
| wallyworld | ok :-( | 01:12 |
| wallyworld | still need that provider-state file then | 01:12 |
| thumper | for now | 01:12 |
| wallyworld | was hoping to avoid an upgrade step | 01:13 |
| davechen1y | menn0: wow, AssertNoChange is nuts | 01:19 |
| davechen1y | start sync, look, and hope that nothing changed | 01:19 |
| davechen1y | so you dn't know if you looked to quickly | 01:19 |
| davechen1y | or if nothing happened | 01:19 |
| davechen1y | or something else went wrong | 01:19 |
| wallyworld | menn0: you got a minute? | 01:43 |
| wallyworld | or thumper | 01:43 |
| wallyworld | got a migration question | 01:43 |
| menn0 | wallyworld: hi, yep | 02:07 |
| wallyworld | menn0: quick hangout? | 02:07 |
| menn0 | wallyworld: sure | 02:08 |
| wallyworld | https://hangouts.google.com/hangouts/_/canonical.com/tanzanite-stand | 02:08 |
| wallyworld | axw: ^^^ | 02:08 |
| mup | Bug #1594290 changed: Duplicate key error on juju.txns.stash creating model <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1594290> | 02:19 |
| davechen1y | menn0: thanks for your suggetiosn | 02:22 |
| davechen1y | i have PR that makes that test a little less crackful | 02:23 |
| menn0 | davechen1y: awesome. let me know if you need a review. | 02:24 |
| thumper | menn0, wallyworld: trivial fix http://reviews.vapour.ws/r/5114/ | 02:44 |
| wallyworld | ok | 02:44 |
| menn0 | thumper: double ship it | 02:45 |
| wallyworld | thumper: jeez, what a bad assert | 02:45 |
| thumper | cheers | 02:45 |
| thumper | I'll just backport to 1.25 | 02:46 |
| natefinch | who wants to review some windows code? Fun for young and old! https://github.com/natefinch/npipe/pull/21 | 02:55 |
| natefinch | (also short and easy) | 02:56 |
| davechen1y | menn0: allwatcher_internal_test.go:3106: c.Assert(len(d), gc.Equals, 0) | 03:00 |
| davechen1y | ... obtained int = 1 | 03:00 |
| davechen1y | ... expected int = 0 | 03:00 |
| davechen1y | yay | 03:00 |
| davechen1y | i fixed it | 03:00 |
| davechen1y | now the other test fails ... | 03:00 |
| davechen1y | fml | 03:00 |
| menn0 | davechen1y: progress! ;-) | 03:01 |
| davechen1y | sorta | 03:03 |
| davechen1y | also, witness the brilliance of gocheck | 03:04 |
| davechen1y | http://paste.ubuntu.com/17630317/ | 03:04 |
| davechen1y | which of the six calls to AssertNoChange on this page failed ? | 03:04 |
| davechen1y | there is a prize if you guess the correct one | 03:04 |
| davechen1y | 'cos I sure af don't know | 03:05 |
| wallyworld | axw: oh yeah, also, there's currently no exposed method to get the name of the model's cloud that i can see; there's st.Cloud() but that doesn't expose the nme from the cloudDoc | 03:07 |
| wallyworld | did we want to use a bespoke struct which maybe embeds cloud.Cloud | 03:07 |
| axw | wallyworld: State.ControllerInfo() has it | 03:08 |
| wallyworld | ah rightio | 03:08 |
| axw | wallyworld: I think we'll end up adding it to Model tho | 03:08 |
| wallyworld | i thiknk so yeah | 03:08 |
| axw | a new method, CloudName() string | 03:08 |
| wallyworld | i'll stick with what we have for now | 03:08 |
| natefinch | davechen1y: it's not fair to blame bad tests on the framework. It would be just as bad with the default test infrastructure | 03:08 |
| wallyworld | can iterte | 03:08 |
| davechen1y | natefinch: false | 03:09 |
| davechen1y | t.Errorf(...) // will print this exact line | 03:10 |
| davechen1y | it does mean you cannot write test helpers | 03:10 |
| davechen1y | but that was something that rob pike hates | 03:10 |
| davechen1y | for reasons that I don't understand | 03:10 |
| natefinch | my general approach to tests is that DRY is an extreme anti-pattern in tests. You want the code right in your face as much as possible. | 03:11 |
| * thumper looks at how to reapply a diff | 03:13 | |
| natefinch | this kind of failure message is one reason why I hate table driven tests. You have to be really really careful about how you code them, or they are super confusing when they fail. The latest addition to the go test framework makes that significantly better, but not perfect. | 03:13 |
| davechen1y | thumper: FUK FUK FUK | 03:18 |
| davechen1y | now i've broken the test the other way | 03:18 |
| thumper | heh | 03:18 |
| davechen1y | AssertNoChange now randomly reports some bullshit results | 03:18 |
| thumper | oops | 03:23 |
| davechen1y | this is like when you're working on the car | 03:25 |
| davechen1y | you;ve got the engine disconnected from the transmission and you discover you need a part from the store | 03:25 |
| davechen1y | and you've just taken your car apart | 03:25 |
| natefinch | davechen1y: http://www.dailymotion.com/video/x2gp98t | 03:28 |
| thumper | wallyworld: http://reviews.vapour.ws/r/5118/ serialization tag reintroduction | 03:29 |
| thumper | wallyworld: what did I get wrong last time? | 03:29 |
| wallyworld | storagesize | 03:29 |
| thumper | wallyworld: can I get you to cast your eyes over the diff | 03:30 |
| thumper | and just open issues for all wrong bits? | 03:30 |
| wallyworld | yep looking | 03:30 |
| thumper | I'll fix before landing | 03:30 |
| thumper | cheers | 03:30 |
| wallyworld | thumper: diff looks like you got branches mixed up | 03:30 |
| thumper | wat? | 03:31 |
| * thumper looks | 03:31 | |
| wallyworld | hmm maybe not | 03:31 |
| wallyworld | just saw the first few changes | 03:31 |
| wallyworld | looked unrelated | 03:31 |
| thumper | no | 03:31 |
| thumper | there were issues where the api was doing bad things | 03:31 |
| thumper | like using its own structs | 03:31 |
| thumper | or passing through state structures | 03:31 |
| wallyworld | gawd | 03:32 |
| thumper | wallyworld: also, if testing was inside a goroutine | 03:32 |
| thumper | I ended up changing the Asserts for Checks | 03:32 |
| thumper | because you souldn't assert in a go routine | 03:33 |
| wallyworld | yay, good catch | 03:33 |
| thumper | full test suite run is running locally for that branch | 03:33 |
| thumper | making my fan howl | 03:33 |
| menn0 | wallyworld: so as fwereade pointed out in a review yesterday, it's a bug that the client side watchers (in api/watcher) could still be doing stuff (like calling the Stop API for a watcher) after the client side watcher has indicated it is done | 03:43 |
| menn0 | wallyworld: I think I know how to fix it (using catacombs) but it's a non-trivial amount of work | 03:44 |
| wallyworld | menn0: which bug? sorry lack context | 03:44 |
| menn0 | wallyworld: http://reviews.vapour.ws/r/5106/ the remaining open issue | 03:47 |
| menn0 | wallyworld: the test is even worse than it needs to be because it the Stop call happens in a goroutine that might still be running after the client side watcher is dead | 03:48 |
| wallyworld | menn0: i reckon land it and fix later, it's not like this PR introduces the bug | 03:49 |
| menn0 | the problem is the way commonWatcher (api/watcher) integrates with the specific watcher types | 03:49 |
| menn0 | wallyworld: i've already landed the PR ... just wondering about fixing the problem in a separate PR | 03:50 |
| menn0 | I might just do Will's suggestion and have the worker take a watcher constructor | 03:50 |
| menn0 | and file a bug about the broken watcher behaviour | 03:50 |
| wallyworld | sgtm, incremental progress | 03:50 |
| menn0 | kk | 03:50 |
| menn0 | wallyworld: thanks for being a rubber duck :) | 03:51 |
| wallyworld | quack quack | 03:51 |
| natefinch | anyone care to rubberstamp a deps update that fixes a blocking bug? http://reviews.vapour.ws/r/5119/diff/# | 03:55 |
| wallyworld | natefinch: lgtm | 03:56 |
| wallyworld | thumper: i marked the typo in the pr | 03:56 |
| thumper | wallyworld: cool | 04:06 |
| davechen1y | thumper: menn0 https://github.com/juju/juju/pull/5676 | 04:16 |
| davechen1y | took the easy way out | 04:16 |
| menn0 | davechen1y: looking | 04:17 |
| menn0 | davechen1y: not sure if that's a good idea | 04:17 |
| menn0 | davechen1y: that makes the testWatcher.AssertNoChange calls take 10s right? | 04:17 |
| menn0 | if the code is behaving correctly and there is in fact no change | 04:18 |
| menn0 | davechen1y: that's why I was suggesting that there might need to be a more invasive change | 04:18 |
| menn0 | davechen1y: maybe NumDeltas should go away, and AssertNoChange and AssertChange should have independent implementations | 04:19 |
| davechen1y | menn0: i tried that | 04:21 |
| davechen1y | it jsut make a mess | 04:21 |
| davechen1y | i did that | 04:21 |
| davechen1y | menn0: http://paste.ubuntu.com/17632486/ | 04:21 |
| davechen1y | now AssertNoChange fails reliably ... :( | 04:21 |
| menn0 | davechen1y: hmmm | 04:25 |
| menn0 | davechen1y: i'm not exactly sure what's happening there | 04:25 |
| menn0 | davechen1y: is len(d) > 0 when a change is detected? | 04:25 |
| menn0 | (where d is the actual deltas) | 04:25 |
| davechen1y | yup | 04:26 |
| davechen1y | if there is no change, then nothing should be deliverd on tw.delta | 04:26 |
| menn0 | davechen1y: could it be that there's deltas not being completely consumed from the previous change? | 04:33 |
| menn0 | davechen1y: FWIW I'm pretty sure AssertChanges in your diff should be using LongWait, not ShortWait | 04:34 |
| davechen1y | menn0: this is all rubbish | 04:34 |
| davechen1y | make a chage | 04:34 |
| davechen1y | wait to see if anything happened | 04:34 |
| davechen1y | maybe something happened, maybe didn't wait long enough | 04:35 |
| davechen1y | reverse the logic for _not_ expecting a change | 04:35 |
| davechen1y | there is no synchonisation, only waiting | 04:35 |
| davechen1y | i'm amazed this works at all | 04:35 |
| menn0 | welcome to watchers | 04:35 |
| davechen1y | what a bunch of bollocks | 04:37 |
| mup | Bug #1594663 opened: Client side watchers may still be active when they report themselves as dead <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1594663> | 05:07 |
| mup | Bug #1594665 opened: reboot-executor is missing from the list of workers <juju-core:New for fwereade> <juju-core model-migration:New> <https://launchpad.net/bugs/1594665> | 05:07 |
| menn0 | thumper or wallyworld : addresses an issue fwereade raised in a previous PR: http://reviews.vapour.ws/r/5106/ | 05:31 |
| wallyworld | ok | 05:31 |
| menn0 | wallyworld: sorry, wrong PR: http://reviews.vapour.ws/r/5121/ | 05:34 |
| wallyworld | tis ok, found it already | 05:34 |
| menn0 | wallyworld: at least it was the one where fwereade raised the issue :) | 05:35 |
| wallyworld | menn0: i just had a quibble / question about end-end test coverage, but it does look far less complicated | 05:38 |
| menn0 | wallyworld: and I don't think we really lost any coverage here... the API call was fake before | 05:39 |
| menn0 | wallyworld: it's just avoiding testing stuff that is actually in another package and tested there | 05:39 |
| wallyworld | rightio | 05:40 |
| menn0 | wallyworld: agreed on the end-to-end test. there will be a feature tests added, and CI tests of course, as everything comes together | 05:40 |
| wallyworld | sgtm | 05:40 |
| menn0 | wallyworld: veebers is on the case with the CI test | 05:40 |
| wallyworld | \o/ | 05:40 |
| davechen1y | menn0: this is terrible | 06:21 |
| davechen1y | menn0: thumper https://github.com/juju/juju/pull/5678 | 07:14 |
| davechen1y | attempt #2 | 07:14 |
| frobware | dimitern: want to skip 1:1? I want to go through some of the things we discussed with jay last night before standup. | 07:38 |
| dimitern | frobware: sure, np | 07:38 |
| dimitern | frobware: I've picked up bug 1594580 anyway | 07:39 |
| mup | Bug #1594580: lxd container invalid parent device name <blocker> <bundles> <ci> <lxd> <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1594580> | 07:39 |
| frobware | dimitern: one useful tidbit is: sudo cat /proc/net/bonding/bond0 | 07:39 |
| frobware | dimitern: the info in there (and must run as root) tells you whether the LACP setup actually happened. | 07:39 |
| dimitern | frobware: that's useful to know indeed! | 07:40 |
| menn0 | davechen1y: reviewed | 07:40 |
| dimitern | frobware: I've decided against trying to set up bonding on the nucs for now | 07:41 |
| frobware | dimitern: makes sense in absence of h/w :) | 07:41 |
| dimitern | frobware: yeah :) | 07:42 |
| frobware | dimitern: I woild not suggest the nuc I bought - too slow and the lack of AMT is a pain | 07:42 |
| dimitern | frobware: what cpu did it have? dual-core celeron? | 07:44 |
| frobware | dimitern: yep, though it may have threads, so 4. | 07:44 |
| dimitern | frobware: but still.. celeron :) | 07:44 |
| davechen1y | menn0: thanks, i'll try to integrate some more "wait this long, max" logic | 07:53 |
| menn0 | davechen1y: cool | 07:55 |
| axw | wallyworld: this change I'm working on is excruciating, and unlikely to be ready by beta10. I think I'll take a break tomorrow and fix some of the bugs raised on beta9 | 08:05 |
| axw | and when I say "unlikely", I mean "almost certainly not" | 08:06 |
| === Spads_ is now known as Spads | ||
| anastasiamac | axw: is this json for gce? | 08:16 |
| axw | anastasiamac: not working on that yet, will probably look tomorrow | 08:17 |
| axw | anastasiamac: hve been looking at some fundamental changes to model config / cloud / credential separation | 08:17 |
| anastasiamac | axw: k. thnx \o/ | 08:17 |
| mup | Bug #1594720 opened: 2.0 b9: Fail to deploy LXD container in restricted network <juju-core:New> <https://launchpad.net/bugs/1594720> | 08:56 |
| jam | dimitern: voidspace: standup | 09:02 |
| jam | ? | 09:02 |
| dimitern | sorry, omw | 09:02 |
| babbageclunk | dimitern, voidspace: hmm - why didn't this PR get a review created? Is it because I ended with a comment in parens? https://github.com/juju/juju/pull/5679 | 09:38 |
| voidspace | babbageclunk: no idea... | 09:39 |
| voidspace | babbageclunk: ask ericsnow when he comes online | 09:39 |
| voidspace | babbageclunk: every now and then this happens | 09:39 |
| babbageclunk | voidspace: ugh, that's ages away | 09:39 |
| voidspace | babbageclunk: yep | 09:39 |
| babbageclunk | voidspace: I'll try a little chicken-slaughtering to see if that helps. | 09:40 |
| babbageclunk | voidspace: Yeah! I'm the boss of computers! | 09:42 |
| babbageclunk | voidspace: I mean, it could just have been a coincidence, but that superstition is sticking from now on! | 09:44 |
| TheMue | morning | 09:47 |
| babbageclunk | dimitern, voidspace, frobware: reviews welcomed! http://reviews.vapour.ws/r/5123 | 09:51 |
| dimitern | babbageclunk: I'll have a look in a bit | 09:51 |
| babbageclunk | dimitern: cool thanks - no big rush | 09:51 |
| babbageclunk | niemeyer1: ping? | 10:18 |
| voidspace | babbageclunk: heh, I didn't realise chicken sacrifices helped | 10:21 |
| voidspace | babbageclunk: I don't have any chickens but I do have two children, maybe I could spare one of them... | 10:21 |
| babbageclunk | I think children are worth between 5-10 chickens. | 10:22 |
| voidspace | babbageclunk: so worth waiting for a really serious bug | 10:24 |
| voidspace | babbageclunk: hmmm... I wonder if sacrificing both would fix our issues with /en/n/i | 10:24 |
| voidspace | might actually be worth it... | 10:25 |
| voidspace | we can always grow some more | 10:25 |
| babbageclunk | voidspace: tsk | 10:25 |
| frobware | voidspace: well, no chickens or children needed. A sleep of 0.5s between ifdown/up seems to cure it. \o/ | 11:28 |
| babbageclunk | frobware: yay! | 11:33 |
| babbageclunk | frobware: that's better than a 10min reboot. | 11:33 |
| frobware | babbageclunk: give or take, about 10mins. :) | 11:33 |
| frobware | babbageclunk: I cut & paste the commands we run and ran them "by hand" in the shell.. it was then I noticed that it worked. Put the same commands back in a shell script and it all fails. | 11:34 |
| babbageclunk | frobware: dumb computers doing stuff too fast for themselves. | 12:02 |
| frobware | babbageclunk: agreed. if we would all slow down we'd get there faster :P | 12:03 |
| voidspace | frobware: that's great | 12:49 |
| mup | Bug #1571053 opened: container networking lxd 'invalid parent device' <ci> <lxd> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1571053> | 13:51 |
| natefinch | cherylj: have a bug you'd like me to work on? | 13:53 |
| cherylj | natefinch: Of course! Want to take a look at bug 1593299 ? | 13:55 |
| mup | Bug #1593299: HA recovery fails in azure <azure-provider> <blocker> <ci> <ha> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1593299> | 13:55 |
| natefinch | cherylj: I figured that might be your answer, being the only blocker not in progress. Sure thing. | 13:56 |
| cherylj | I'm sorry I'm so predictable | 13:56 |
| cherylj | ;) | 13:56 |
| natefinch | :) | 13:56 |
| natefinch | oh azure, that special flower... | 13:57 |
| frankban | cherylj: hi, do you know more or less when master will be unblocked so that I can merge a couple of little contributions I have? | 14:24 |
| cherylj | frankban: if you send me the PRs, I'll evaluate and merge it for you | 14:25 |
| frankban | cherylj: http://reviews.vapour.ws/r/4936/ and http://reviews.vapour.ws/r/5124/ (though the latter could wait for another review) | 14:25 |
| mup | Bug #1571053 changed: container networking lxd 'invalid parent device' <ci> <lxd> <juju-core:Fix Released by frobware> <https://launchpad.net/bugs/1571053> | 14:30 |
| alexisb | frobware, just need a few minutes for a cup of coffee | 14:31 |
| alexisb | brt | 14:31 |
| dimitern | frobware, voidspace: a tiny-ish review fixing bug 1594590, please take a look - http://reviews.vapour.ws/r/5125/ | 14:40 |
| mup | Bug #1594590: [needs packaging] arc-theme <Ubuntu:In Progress by fossfreedom> <Debian:New> <https://launchpad.net/bugs/1594590> | 14:40 |
| dimitern | oops not that one | 14:40 |
| voidspace | dimitern: I don't believe you ever produce small reviews | 14:41 |
| voidspace | but I'm willing to be surprised | 14:41 |
| dimitern | voidspace: :) you might be surprised | 14:41 |
| dimitern | let's try again mup.. bug 1594580 | 14:41 |
| mup | Bug #1594580: lxd container invalid parent device name <blocker> <bundles> <ci> <lxd> <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1594580> | 14:42 |
| cherylj | frankban: I kicked off the merge for the first PR. Let me know when you get another review for the second | 14:43 |
| natefinch | OMG https://jujucharms.com/docs/devel/help-azure | 14:44 |
| natefinch | sudo apt-get install -y nodejs-legacy npm | 14:45 |
| natefinch | WTF | 14:45 |
| frankban | cherylj: ty! | 14:46 |
| cherylj | natefinch: you can grab the CI creds and not have to do all that | 14:46 |
| voidspace | dimitern: LGTM | 14:47 |
| natefinch | cherylj: thanks... I have azure set up from forever ago, so in theory, I just need to grab those values off the website or something... it's just... do we really expect someone to follow this 15 (yes, I counted) step process | 14:47 |
| dimitern | voidspace: cheers! | 14:49 |
| frankban | perrito666: could you please take a look at replies at http://reviews.vapour.ws/r/5124/ ? what do you think? | 14:50 |
| perrito666 | frankban: I see, well we can always change if we need something else in the future, as roger says | 14:51 |
| frankban | perrito666: so can I go ahead and ship it? | 14:52 |
| perrito666 | frankban: you have a shipit from roger :p he just forgot to click the button | 14:53 |
| perrito666 | frankban: is master unlocked? | 14:53 |
| frankban | perrito666: no, I'll handle that, I'd like to have a ship it from a core dev | 14:53 |
| perrito666 | frankban: sure, ship it | 14:56 |
| perrito666 | (I added the shipit to the pr) | 14:56 |
| frankban | perrito666: thanks | 14:57 |
| mup | Bug #1594855 opened: MAAS provider bridge script on trusty does not handle LACP bonds <addressability> <maas-provider> <network> <trusty> <juju-core:Triaged> <juju-core 1.25:New> <https://launchpad.net/bugs/1594855> | 15:03 |
| katco | ericsnow: standup time | 15:06 |
| cherylj | natefinch: would you be able to port your fix for bug 1581157 to 1.25? | 15:10 |
| mup | Bug #1581157: github.com/juju/juju/cmd/jujud test timeout on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Committed by natefinch> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1581157> | 15:10 |
| dimitern | cherylj: hey, re 1.25.6 - still planned to ship tomorrow? | 15:13 |
| natefinch | cherylj: yeah. it's just a deps change | 15:13 |
| cherylj | thanks, natefinch | 15:14 |
| cherylj | dimitern: I don't think it'll be tomorrow | 15:14 |
| cherylj | dimitern: but we should try for this week | 15:14 |
| dimitern | cherylj: ok, cheers | 15:14 |
| cherylj | dimitern: are you asking for bug 1594855? | 15:14 |
| mup | Bug #1594855: MAAS provider bridge script on trusty does not handle LACP bonds <addressability> <maas-provider> <network> <trusty> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1594855> | 15:14 |
| dimitern | cherylj: yeah, exactly :) | 15:14 |
| dimitern | cherylj: it's affecting a customer | 15:15 |
| mup | Bug #1593838 opened: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1593838> | 15:15 |
| cherylj | dimitern: k, do you have an ETA on the fix? | 15:15 |
| dimitern | cherylj: likely tomorrow - frobware is testing a fix already | 15:16 |
| dimitern | cherylj: we've (more or less) established the root cause at least | 15:17 |
| cherylj | ok, cool | 15:17 |
| cherylj | dimitern: did someone ask you about bug 1590598 too? | 15:17 |
| mup | Bug #1590598: ipv6 interfaces configured on a machine (in maas) are not added to lxc containers deployed to that machine <sts> <juju-core:Confirmed> <MAAS:Invalid> <https://launchpad.net/bugs/1590598> | 15:17 |
| dimitern | cherylj: nope, looking.. | 15:17 |
| cherylj | dimitern: you had a comment in there that "we'll address this soon", and wanted to know if this was still on your radar | 15:18 |
| dimitern | cherylj: ah, I remember this one | 15:18 |
| dimitern | cherylj: yeah, it's a known limitation atm | 15:18 |
| cherylj | dimitern: is it something we want to commit to for 2.0? or does it need more time and should be deferred to 2.1? | 15:18 |
| dimitern | cherylj: I'd say 'good to have for 2.0', but realistically - 2.1 | 15:19 |
| cherylj | dimitern: is it large enough that it needs to be sized and budgeted for (headcount wise)? | 15:20 |
| dimitern | cherylj: it's not inherently difficult, there are more serious issues we're focusing on first | 15:20 |
| cherylj | dimitern: k, thanks | 15:20 |
| mup | Bug #1593838 changed: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1593838> | 15:21 |
| mup | Bug #1593838 opened: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1593838> | 15:30 |
| mup | Bug #1594865 opened: 2.0 beta8: deployment with sphere as provider - bootstrap node - no space left on / <oil> <juju-core:New> <https://launchpad.net/bugs/1594865> | 15:45 |
| natefinch | cherylj, sinzui: where are the juju 2.0 CI credentials for azure stored? In cloud-city somewhere, I presume? | 15:58 |
| cherylj | natefinch: yeah, in cloud-city | 15:58 |
| cherylj | natefinch: need a refresher on how to access? | 15:58 |
| natefinch | cherylj: no... I just forgot I hadn't updated my branch of it in like a year | 15:59 |
| natefinch | cherylj: credentials.yaml looks promising :) | 15:59 |
| sinzui | natefinch: cloud-city, look in credentials.uaml | 15:59 |
| natefinch | ahhhh azure is so slow | 16:07 |
| natefinch | whoever added model/controller/cloud/version to juju status, thank you! | 16:12 |
| natefinch | cherylj: do you know who did the updates to juju status? looks like it's fixed in current master, but the bug hasn't been updated: https://bugs.launchpad.net/juju-core/+bug/1571792 | 16:17 |
| mup | Bug #1571792: Juju status should show controller and model names <juju-release-support> <rc1> <status> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1571792> | 16:17 |
| cherylj | natefinch: that was thumper, I think | 16:18 |
| mup | Bug #1594875 opened: Please alias 'relate' to 'add-relation' <juju-core:New> <https://launchpad.net/bugs/1594875> | 16:21 |
| tvansteenburgh | wallyworld: you around? | 16:28 |
| tvansteenburgh | wallyworld: i'm working on getting jujuclient working with beta9. looks like top-level status keys were switched to lowercase, is that right? is it only the top level keys? | 16:29 |
| tvansteenburgh | anyone else know? ^ | 16:35 |
| === frankban is now known as frankban|afk | ||
| tvansteenburgh | nevermind, i think i found the answer | 16:40 |
| mup | Bug #1594883 opened: initial juju status is really ugly <status> <juju-core:New> <https://launchpad.net/bugs/1594883> | 16:55 |
| alexisb | tvansteenburgh, you should have a mail in your inbox that provides some input, thumper can provider more backgroun to qs when he comes online | 17:04 |
| alexisb | natefinch, thank you for you input on lp 1594883 | 17:05 |
| tvansteenburgh | alexisb: thanks | 17:09 |
| rogpeppe1 | here's a fun review if anyone wants to take a look: https://github.com/juju/juju/pull/5684 | 17:21 |
| rogpeppe1 | it adds redirect support when making API connections | 17:22 |
| perrito666 | Rogpeppe1 I'll review after lunch | 17:36 |
| alexisb | rogpeppe1, for your PR, did you work with anyone on the techboard, or someone else on the core team? | 17:43 |
| mup | Bug #1594924 opened: resource-get is painfully slow <juju-core:New> <https://launchpad.net/bugs/1594924> | 17:55 |
| mup | Bug #1594924 changed: resource-get is painfully slow <juju-core:New> <https://launchpad.net/bugs/1594924> | 18:01 |
| mup | Bug #1594924 opened: resource-get is painfully slow <juju-core:New> <https://launchpad.net/bugs/1594924> | 18:07 |
| ejat | axw: r u there | 18:11 |
| perrito666 | bbl | 18:26 |
| Yash1 | katco: Hey :) | 18:51 |
| katco | Yash1: o/ | 18:51 |
| * redir steps out for some air. bbiab. | 19:37 | |
| === redir is now known as redir_afk | ||
| aisrael | sinzui: Do you know if it's possible for the juju devel ppa to keep copies of previous beta versions? In this case, I need to rollback to beta 8 in order to run bundletester, but I autoremove'd my apt cache after upgrading to beta 9. | 20:10 |
| sinzui | aisrael: debian/ubuntu does not permited | 20:14 |
| sinzui | aisrael: users can copy packages to less volitile ppas | 20:15 |
| sinzui | aisrael: for CI, we keep a copy of all the clients we release so we can do compatability testing | 20:16 |
| natefinch | aisrael: you can always just copy the binaries to a new folder. put them in a beta8 directory or something | 20:16 |
| aisrael | sinzui: natefinch: is there a way I can get a copy of the beta8 release then? | 20:17 |
| aisrael | I'll start backing them up from now on. :) | 20:17 |
| natefinch | sinzui: do we store the linux binaries somewhere? I see centos and osx and windows on launchpad, but not linux | 20:20 |
| natefinch | er not ubuntu | 20:20 |
| sinzui | aisrael Lp has a record of most of what it historically built. I think this helps https://launchpad.net/~juju/+archive/ubuntu/devel/+packages?field.name_filter=juju-core&field.status_filter=superseded&field.series_filter= | 20:21 |
| sinzui | natefinch: QA team stores all clients we release to do client compatability testing. | 20:21 |
| aisrael | sinzui: That's perfect, thanks! | 20:21 |
| mup | Bug #1594958 opened: Bootstrapping on OpenStack fails with juju 2 <juju-core:New> <https://launchpad.net/bugs/1594958> | 20:22 |
| natefinch | it's kind of amusing that we have different builds for different ubuntu series.. as if they're actually any different. If the go tool did it right, they'd probably be bit for bit identical/ | 20:25 |
| perrito666 | its the debian way, which is in the exact oposite of static binary compilations | 20:28 |
| natefinch | hell, the CentOS one I'm sure is also identical. It runs just fine on my machine. Go doesn't care what flavor of linux you're compiling on | 20:28 |
| === redir_afk is now known as redir | ||
| perrito666 | mm, what is the API call to delete a model | 20:47 |
| natefinch | hmm... kill-controller is kind of a confusing command when you're in HA | 20:53 |
| natefinch | I guess if you think of it like the cluster is the controller, not each machine is a controller | 20:54 |
| natefinch | sigh... naming is hard | 20:54 |
| wallyworld | katco: ericsnow: quick catch up? | 21:05 |
| wallyworld | https://hangouts.google.com/hangouts/_/canonical.com/tanzanite-stand | 21:06 |
| katco | wallyworld: brt | 21:06 |
| thumper | anyone want this? http://reviews.vapour.ws/r/5129/diff/# | 21:32 |
| perrito666 | thumper: rb just display errors | 21:33 |
| thumper | because it doesn't show deletions well | 21:33 |
| thumper | summary says deleted | 21:33 |
| perrito666 | yes github says so too :- | 21:33 |
| perrito666 | :p | 21:33 |
| perrito666 | ship it | 21:33 |
| mup | Bug #1594977 opened: juju-1 bootstrap forgets about metadata-source argument <v-pil> <juju-core:New> <https://launchpad.net/bugs/1594977> | 21:52 |
| mup | Bug #1594977 changed: juju-1 bootstrap forgets about metadata-source argument <v-pil> <juju-core:New> <https://launchpad.net/bugs/1594977> | 22:01 |
| bdx | hey whats up guys? - Quick question, will there be a 'destroy-machine' command in the future? | 22:13 |
| mup | Bug #1594977 opened: juju-1 bootstrap forgets about metadata-source argument <v-pil> <juju-core:New> <https://launchpad.net/bugs/1594977> | 22:13 |
| bdx | On that, would it be wise, or confusing to refactor references to "DestroyMachine" or "DestroyedMachines" or whatever variation of 'destroy machine' to a similar variation of 'remove machine'? | 22:15 |
| thumper | bdx: there will be a command that removes a machine | 22:18 |
| bdx | thumper: you mean "destroys" | 22:19 |
| thumper | I think we called it 'remove-machine' | 22:19 |
| thumper | destroy was always an alias | 22:19 |
| thumper | we went for naming consistency | 22:19 |
| bdx | I see, yea | 22:19 |
| bdx | so should references in the code base like "DestroyMachine" be refactored to "RemoveMachine" ? | 22:20 |
| bdx | 'destroying' machine operations are carried out by the code, but 'destroying' a machine is not a user facing command? | 22:21 |
| bdx | thumper: what I'm getting at is the inconsistency between destroy-machine ops in the codebase, and the fact that destroying a machine isn't really an operation that can be performed | 22:25 |
| bdx | thumper: should "destroy-machine" references in the codebase be refactored to "remove-machine", also the naming of the functions and classes that reference "destroying" a machine ...? | 22:26 |
| thumper | not entirely sure right now, my head is elsewhere | 22:27 |
| cherylj | menn0: thank you for the review! :) | 22:36 |
| menn0 | cherylj: No problems. I confess to not checking every single change in detail. | 22:36 |
| cherylj | ha, I won't tell | 22:37 |
| wallyworld | axw: perrito666: be right there | 23:15 |
| perrito666 | going | 23:15 |
| anastasiamac | wallyworld: axw: there too :) | 23:18 |
| perrito666 | menn0: thumper any of you know off hand what is the API call to delete model? | 23:58 |
| * wallyworld has coffee emergency, bbiab | 23:58 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!