waigani_thanks for the review thumper00:07
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
menn0wallyworld, thumper: joyent fix: http://reviews.vapour.ws/r/633/03:31
menn0wallyworld, thumper: I spent a long time trying to make a unit test for this work03:32
menn0wallyworld, thumper: but it looks like there's something missing from the fake Joyent API implementation03:32
wallyworldmenn0: lgtm03:35
anastasiamac_menn0: u r a Joyent champion now :D03:35
menn0wallyworld: cheers. Just fixing commit message text as it doesn't quite make sense and will then merge.03:38
menn0anastasiamac_: oh no you don't... :)03:38
wallyworldhey yeah, that gets me off the hook :-D03:39
anastasiamac_menn0: kkkk... if u get CI unblocked - then u r  a champion?...03:39
anastasiamac_wallyworld: there mayb a room for joyent fan club...03:40
menn0anastasiamac_: maybe, but I don't think this is the entire fix because Joyent is consistently failing for master03:40
menn0anastasiamac_: I think there might be another problem to fix yet03:40
menn0anastasiamac_: looking at that now03:40
anastasiamac_menn0: there must b - it would not b xmas without more problems to fix :p03:41
anastasiamac_menn0: thnx!03:41
mattywmenn0, ping?03:54
menn0mattyw: pong!03:57
thumpersorry, was drinking coffee and arguing with kids on holiday04:01
thumperanastasiamac_: I feel like you type like teenagers text now :-)04:02
anastasiamac_thumper: why?04:02
thumper'u' 'r'04:04
thumpermenn0: I see that wallyworld has reviewed already and I don't need to do anything04:05
menn0thumper: correct :)04:06
anastasiamac_thumper: i think and type young04:21
* anastasiamac_ considers whether it's worthwhile to be offended04:24
thumperno, don't be offende04:28
menn0wallyworld, thumper: the merge job seems to have gotten stuck.04:31
menn0wallyworld, thumper: it's been like this for a long time: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1595/console04:31
thumpermenn0: I'd give it 20 minutes04:32
wallyworldi've seen it take a while04:32
thumpermenn0: how long?04:32
menn0thumper: at least half an hour at this point in the tests04:33
menn0i'm running the apiserver tests for this branch locally now04:33
thumperthe test timeout is 20 minutes04:33
thumperand there are multiple slow packages there04:33
thumperand it buffers the output04:33
thumperso it is hard to say04:34
menn0thumper: ok, so i'll wait04:34
thumperbut normally it is done in under 20 minutes for everything...04:34
thumperso perhaps it is wedged04:34
thumperwallyworld: do you know how to kick it right?04:34
wallyworldi can restart it04:34
menn0wallyworld, thumper: the apiserver tests have gotten past that point on my machine already04:35
wallyworldmenn0: thumper: jon restarted04:36
menn0wallyworld: cheers04:36
anastasiamac_do i need something special for juju/names?04:37
anastasiamac_I am getting http://pastebin.ubuntu.com/9524130/04:37
thumperanastasiamac_: shouldn't do, let me check04:38
thumperanastasiamac_: pretty sure that access control is for everything under github.com/juju04:38
thumperanastasiamac_: nope, you are there04:39
thumperanastasiamac_: what is your remote set to?04:39
anastasiamac_thumper: i ran git remote add upstream https://github.com/juju/names.git04:40
anastasiamac_remote set-url origin git@github.com:anastasiamac/names.git04:40
thumperanastasiamac_: have you forked it?04:41
thumperon github?04:41
anastasiamac_thumper: :D yes04:41
thumperonly asking because I have forgotten before04:41
anastasiamac_thumper: i forked it first04:41
anastasiamac_then ran cmds above04:41
thumperanastasiamac_: FYI, I would do the following:04:42
anastasiamac_i can do pretty much everything - run status, etc... but cannot pull ;(04:42
thumpergit remote --set-url upstream git@github.com/juju/names.git04:42
thumpergit remote --set-url --push upstream no-pushing04:42
thumperthe git wire protocol is much faster than https04:43
axwanastasiamac_: dumb question, have you added your public SSH key to GitHub?04:43
axw(are you using SSH for juju/juju?)04:44
anastasiamac_axw: i must have to commit to juju/juju no?04:44
axwthere are other transports04:44
anastasiamac_axw: dunno... how can i find out what m using for juju/juju04:44
anastasiamac_axw: ?04:44
axwanastasiamac_: "git remote -vv" in the local repo04:44
anastasiamac_axw: fetch and pull for origin and upstream are prefixed with https04:46
axwanastasiamac_: right, so you're not using SSH. if you want to use it, then you should add your public key in your user settings on GitHub04:47
axwanastasiamac_: https://github.com/settings/ssh04:47
anastasiamac_axw: i dont want ssh :)04:48
anastasiamac_axw: but m seeing the diff btw how my juju/juju and juju/names are setup..04:48
anastasiamac_axw: let me align them with party line04:48
axwanastasiamac_: git remote set-url origin https://github.com/anastasiamac/names.git04:50
thumperanastasiamac_: why don't you want ssh?04:50
thumperssh is awesome04:50
axwif you really don't want SSH... I would use it though, you don't need to keep putting your password in04:50
anastasiamac_axw: thnx. i've sorted and will consider ssh :D u r awesome!04:52
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
menn0and we have a new CI blocker....05:14
mupBug #1402495: Joyent deploys fail in CI <ci> <joyent-provider> <regression> <juju-core:New> <https://launchpad.net/bugs/1402495>05:14
menn0with the Joyent routing issue fixed, this CI with Joyent issue remains05:15
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
mattywfolks - is juju/utils a review board project now?06:50
anastasiamac_mattyw: it looks like it :-)07:09
mattywanastasiamac_, :) I was sure I saw an old email that said it was, I saw it and went for it :)07:12
=== urulama_ is now known as urulama
=== negronjl is now known as negronjl_afk
dimiternmorning TheMue09:02
dimiternTheMue, 1:1?09:02
dimiternfwereade, hey09:05
dimiternfwereade, if you're around today, and hopefully feeling better, can I trouble you for a review on http://reviews.vapour.ws/r/611/ please?09:07
TheMuedimitern: oh, eh, yes, coming09:10
fwereadedimitern, not better, but looking anyway, because it looks completely awesome from the description and I feel bad for not having done it on fri09:28
dimiternfwereade, cheers :)09:28
dimiternmorning perrito666, voidspace09:50
fwereadedimitern, that's *awesome*, LGTM with trivials09:55
fwereadedimitern, check with TheMue about YamlEquals though09:55
voidspacedimitern: morning09:55
voidspaceperrito666: o/09:55
dimiternfwereade, thank you very much!09:55
voidspacefwereade: o/09:55
voidspacefwereade: sorry you're still unwell09:56
voidspacemy wife brought a cold into the house - she's had it for more than two weeks09:56
voidspaceand it's been rumbling on and off with me for a week09:56
voidspacenot bad, just annoying09:56
rogpeppe1fwereade: hiya11:54
rogpeppe1anyone know when it's ok to call "unit-get public-address" from a charm hook?11:56
rogpeppe1is it supposed to be ok to call it in the install hook for example?11:57
rogpeppe1dimitern: ^11:57
dimiternrogpeppe1, it's set when the uniter starts (if it's available) so I'd say right away11:58
rogpeppe1dimitern: ok, thanks11:59
dimiternrogpeppe1, it might not be available if the machine doesn't have an address yet (i.e. still pending/provisioning)12:00
jam1hey axw, wallyworld, maybe we should be chatting here instead :)12:05
dimiternjam1, o/12:05
jam1hi dimitern, how's your day been going?12:06
rogpeppe1dimitern: thanks12:07
rogpeppe1dimitern: one other thing: if you call config-get in an install hook, should you get something sensible?12:07
dimiternjam1, not bad, multitasking already :) with goamz migration, ci blockers and addressability stuff..12:08
dimiternrogpeppe1, you know what - I was just looking at the code and I can't say I'm 100% sure the install hook will have public-address set12:09
jam1rogpeppe1: given you can do "juju deploy —config=" why wouldn't you get config in install ?12:09
dimiternrogpeppe1, better ask fwereade for sure12:09
rogpeppe1jam1: i *think* i'm seeing a null result from config-get in an install hook; i need to check a bit more12:10
fwereaderogpeppe1, config-get should always be fine; I *think* unit-get public address should always work but it's possible that state and/or networking changes have made it "" instead of <whatever the private address is>12:11
rogpeppe1fwereade: ok, thanks. it's probably my code.12:11
fwereaderogpeppe1, sorry I'm not very around today, I'm mostly in bed, will be on a bit later for meetings12:12
rogpeppe1fwereade: aw, gbs12:12
axwjam1: heya. chatting about what? is there a meeting?12:12
wallyworldaxw: jam1 was look at storage spec, but the 15.04 "official" one in the master spec list pointed to the old spec, not the newest, latest one12:13
dimiternfwereade, rogpeppe1, unit-get private-address|public-address always triggers unit.Private|PublicAddress() getting called; however looking at the filter/modes/etc. it seems until we know there's an address (i.e. the addresses watcher returned changes) config-change won't be triggered12:15
fwereadedimitern, not *quite* true, we always get a config-changed after install, so, ha, yes, it's possible that nothing's set the machine's address by the time it's running a unit12:16
rogpeppe1dimitern: the behaviour i *think* i'm seeing (i'm just about the test it) is that config-get is returning a null value even when there's a default value set12:16
rogpeppe1dimitern: this is in the install hook12:16
rogpeppe1s/the test/to test/12:16
fwereaderogpeppe1, that seems odd, for sure, what do you get with --all?12:17
rogpeppe1fwereade: not sure yet - i haven't got a hook context to play with12:17
fwereaderogpeppe1, juju-run?12:17
rogpeppe1fwereade: ok, trying that12:18
rogpeppe1fwereade: should this work? juju run --unit identity/0 -- config-get --all12:19
dimiternrogpeppe1, why config-get ?12:19
fwereaderogpeppe1, can't remember if you use -- or quote the command12:20
dimiternrogpeppe1,  it should be unit-get12:20
rogpeppe1dimitern: i'm interested in config values here12:20
dimiternrogpeppe1, private|public-address is not a config setting, it's a separate thing12:21
rogpeppe1dimitern: yeah, i know. i was asking about public address initially, but i think the problem may lie elsewhere12:21
dimiternrogpeppe1, ah, ok12:22
sinzuidimitern, how goes bug 1397376?15:08
mupBug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>15:08
dimiternsinzui, fixing last suggestions from fwereade and setting to land15:09
dimiternsinzui, I'm already working on the backport for 1.21 as well15:11
dimiternwith markdown everywhere how are you supposed to curse politely? s**t becomes s[bold]t[/bold] :) I guess s\*\*t is the way to go15:14
dimiternsinzui, should I JFDI it?15:33
dimiternDoes not match ['fixes-1401130', 'fixes-1400358']; Build rejected, reporting on proposal - both of these are fix committed btw15:34
sinzuidimitern, __JFDI__ for master15:34
dimiternsinzui, ok15:35
=== kadams54 is now known as kadams54-away
ackkhi, could someone please point me to where should I look to get the info shown in "state-server-member-status" from the delta stream?15:41
perrito666marcoceppi: I think I just opened the doc for comments, could you try?15:43
marcoceppiperrito666: :thumbsup: will circle back in a bit, got other things I need to clear out first15:44
perrito666marcoceppi: np jut shout if it still not open when you try again, google docs hates me sometimes15:44
marcoceppiperrito666: it's open, thanks!15:44
dimiternrogpeppe1, did you just merge http://reviews.vapour.ws/r/636/ into utils?15:47
dimiternrogpeppe1, sinzui, this causes the CI bot to fail with: Extant directories unknown:15:48
dimitern golang.org/x/crypto15:48
sinzuidimitern, looks like something got imported that wasn't documented15:51
dimiternsinzui, that's right - but it's coming from juju/utils15:52
sinzuidimitern, I believe the simple fix is to add it to dependencies.tsv.15:53
sinzuidimitern, I don't think this is like the cases were conflicting or ambiguous licensing prevent the package from being included. We just need to document it15:54
dimiternsinzui, to unblock the bot, yeah15:55
dimiternsinzui, but we need to make sure this doesn't happen again, agreed?15:55
dimiternsinzui, that fits in just perfect with what I wanted to discuss with you guys - bringing juju-core dependencies under the ci bot (or at least the more actively developed ones)15:56
dimiternsinzui, which will force the devs to actually care about the CI/release process more - like adding a dependencies.tsv for juju/utils, etc. and making sure it works before just merging changes15:57
sinzuidimitern, the check_dependencies phase of building the release tarball ensures no deps that aren't in dependencies.tsv are included. The inclusion assumes we checked the license of the package and pinned it to a version we know is good15:57
dimiternsinzui, even simpler fix will be to actually revert rogpeppe1's change to utils and ask him to do it properly :)15:57
sinzuidimitern, yep15:58
dimiternsinzui, that's totally fine and good we have this check15:58
rogpeppe1dimitern: what was the problem with my change to utils?15:58
dimiternsinzui, it actually helped to catch this15:58
=== kadams54-away is now known as kadams54
dimiternrogpeppe1, you added a dependency which wasn't mentioned anywhere and caused the build to potentially fail (it didn't due to a precaution on the bot)15:59
rogpeppe1dimitern: why should that cause the build to fail?15:59
rogpeppe1dimitern: aren't juju deps pinned?15:59
dimiternrogpeppe1, because it's not in dependecies.tsv of juju-core15:59
rogpeppe1dimitern: but juju-core won't be getting the latest version of utils15:59
dimiternrogpeppe1, and the bot verifies all imports are properly listed as deps15:59
rogpeppe1dimitern: because dependencies.tsv will mention an earlier version15:59
dimiternrogpeppe1, that sounds right... hmm why did it happen then?16:00
rogpeppe1dimitern: i don't see why making a change to utils tip could have broken juju-core, unless someone updated juju-core deps improperly16:00
dimiternrogpeppe1, can you please work with sinzui to see how this could've happened and how to fix the bot?16:01
sinzuidimitern, rogpeppe1 is Juju importing a non-master branch in this case?16:01
dimiternI have a pending bugfix which can't land because of that16:01
rogpeppe1dimitern: i'm in a standup right now16:01
rogpeppe1sinzui: not AFAIK16:01
dimiternrogpeppe1, np, later then?16:01
rogpeppe1dimitern: possibly, although i'm quite busy16:02
sinzuithank you rogpeppe1 , that eliminates the common reason for phantom deps16:02
rogpeppe1sinzui: what do you mean by "importing a non-master branch" ?16:02
sinzuidimitern, rogpeppe1 : Go checks out the master branch and gets its deps. Even when we ask for a non-master branch which has different deps, Go will leave the unwanted deps behind16:03
rogpeppe1sinzui: ah, so that'll be the reason this has broken16:05
rogpeppe1sinzui: because tip has dependencies that before-tip doesn't16:05
sinzuirogpeppe1, dimitern 1 fix might be to change the build scripts to remove golang.org/x/crypto. I will consult with mgz_16:07
rogpeppe1sinzui: yeah, ISTR some hack we had to get around this kind of problem16:07
rogpeppe1sinzui: but i can't remember what the official way to do this was16:07
sinzuirogpeppe1, mgz_ pushed a change to a master branch I think. This case is different though.16:09
rogpeppe1sinzui: what we do is we don't use go get at all AFAIR16:10
mgz_yeah, I can hackit out16:10
mgz_we kind of have to use go get in some capacity16:10
mgz_godeps doesn't implement branch/clone16:11
natefinchwhy are unwanted dependencies a problem?16:13
natefinchI can see missing dependencies, but unwanted should just be garbage on disk that we ignore16:14
mgz_natefinch: we package this stuff, and also don't get great feedback from go about what actually goes into the binaries16:15
mgz_so, maybe some new random github package we downloaded doesn't actually end up in the binary... but that does need asserting for licence/security raisins16:17
voidspaceit would be a pain to have to do an emergency security release because of a bug in a package that we're not actually using...16:21
rogpeppe1natefinch: it's good to check that we don't have unwanted deps because it's easy to omit deps from dependencies.tsv16:21
natefinchrogpeppe1: that's true... but the way to do that should be to check that godeps -f produces the same output as dependencies.tsv ... that could also be what we use to determine the files to package16:22
rogpeppe1natefinch: unfortunately it won't16:23
rogpeppe1natefinch: because i haven't come up with a nice way of including windows deps in godeps output yet16:23
rogpeppe1natefinch: i will, but it's more work that i originally thought16:23
natefinchrogpeppe1: oh right... dang16:24
natefinchrogpeppe1: I wonder if the answer is just to switch to godep.... vendor the dependencies, then there's no question about keeping things in sync.16:25
=== kadams54 is now known as kadams54-away
rogpeppe1natefinch: that may well be a reasonable thing to do16:44
sinzuidimitern, could the network fix joyent need a separate change for precise. I see the same kind of log error in cloud-init for precise as last week and the week before16:51
dimiternsinzui, the one menno did?16:55
sinzuidimitern, yes16:55
sinzuir=me mgz_ . Can you merge and deliver it to unblock dimitern16:56
dimiternsinzui, unlikely, might be intermittent16:57
dimiternsinzui, menno's fix is not precise-specific, but then again if what joyent call a "precise image" is very different from the CPC images..16:58
sinzuidimitern, I am going to re-run tests again to capture logs and hope that trusty repeatedly passes16:59
dimiternsinzui, +116:59
mgz_sinzui: sure thing17:00
mgz_sinzui: done - I only pulled the rev in on the juju-core-slave atm as the update all script barfs on an unknown 10. address for me - doesn't seem we have all of them in the .ssh/config on master somwhow?17:05
sinzuimgz_, ssh and pull tip. I need to rethink the ssh/config rules for or private machines17:06
mgz_hm, could I run in from the jenkins master isntead of locally?17:08
voidspacenatefinch: want another puzzle17:15
voidspacenatefinch: ?17:16
voidspacenatefinch: given a cidr I need to calculate the last allocatable IP address, knowing that the *last one* is reserved17:16
voidspacenatefinch: this is what I have: http://pastebin.ubuntu.com/9530758/17:16
voidspacenatefinch: (includes code to work out lowest allocatable one - the first four are reserved too)17:16
voidspacenatefinch: I'm sure there must be a better way...17:18
dimiternmgz_, \o/ ta!17:19
tasdomasa quick question about FormatSmart in juju/cmd - if I pass it a struct, is it supposed to delegate the marshalling to FormatYaml or return an error?17:19
dimiterntasdomas, that's an excellent question - I was poking into it earlier today, let me check..17:20
tasdomasdimitern, the comments on FormatSmart indicate that it should delegate a struct to FormatYaml17:20
tasdomasdimitern, but it seems to me that the default: case in the switch makes that impossible17:20
dimiterntasdomas, yes it appears so17:20
dimiterntasdomas, you refer to the last 3 empty cases?17:21
dimiterntasdomas, and the default as well17:22
tasdomasdimitern, https://github.com/juju/cmd/blob/master/output.go#L7517:22
tasdomasdimitern, yes17:22
dimiterntasdomas, looking at the code invokes a WTF in me17:22
natefinchvoidspace: not sure I understand exactly what you're trying to do... can you give me an example?17:23
tasdomasdimitern, I was trying to use the smart formatter in a side project and passing it a struct returns an error17:23
dimiterntasdomas, well.. I wouldn't recommend using this for anything17:23
tasdomasdimitern, heh, thanks for the recommendation17:23
dimiterntasdomas, it's a (weak) attempt to make the output more pyjuju compatible17:23
dimiterntasdomas, but it's neither well tested nor anyone cares too much it seems17:24
dimiterntasdomas, I'd even say this deserves a bug report17:24
tasdomasdimitern, I see17:24
voidspacenatefinch: when we get a subnet from ec2 the last ip address is reserved17:25
tasdomasdimitern, I'll probably submit a pull request for it17:25
voidspacenatefinch: given the subnet in CIDR format I need to know what is the highest *allocatable* IP address17:25
dimiterntasdomas, that'll be awesome, thanks!17:25
voidspacenatefinch: so, I take the "zeros" portion of the netmask, turn them to ones and OR it with the start IP address of the CIDR17:26
voidspacenatefinch: that gives me the last IP address, from which I subtract one to calculate the last *allocatable* IP address17:27
natefinchvoidspace: ok, so like if you get, then is the "reserved" address, and .254 is the last allocatable one?17:28
natefinchvoidspace: sorry, my networking skills are *really* rusty17:28
voidspacenatefinch: correct17:28
voidspacenatefinch: a CIDR (subnet block) is an IP address plus netmask17:29
voidspacenatefinch: I believe my bit twiddling is correct, just not terribly elegant17:30
voidspacenatefinch: also going via a float (math.Pow) is pretty awful17:31
voidspacenatefinch: is there syntax for an integer power operation?17:31
natefinchvoidspace: math.pow IIRC17:31
voidspacenatefinch: that's float17:32
voidspacenatefinch: which I'm using currently17:32
natefinchvoidspace: just cast back and forth unless you think you'll run off the top of float6417:33
voidspacenatefinch:    highMask := uint32(math.Pow(2, float64(zeros))) - 117:33
voidspaceyuck :-)17:33
natefinchsomebody might have made a copy of the package for integers17:34
jw4OCR PTAL : Fixes Go 1.4 vet error that blocks pre-push hook: (got approval, just looking for senior reviewer sign off) http://reviews.vapour.ws/r/630/17:41
natefinchjw4: FYI we shouldn't be building with 1.4.... though if we're at still backwards compatible with 1.2, that's fine, I guess.17:45
jw4natefinch: I see - I figured its fine to develop in 1.4 assuming that the CI tests are all running in 1.2.1 or whatever the supported version is17:46
natefinchjw4: yeah, like I said, it's fine, but I think it does break some tests.17:47
jw4natefinch: Interesting.  I'm pretty sure we found and fixed some tests that were broken by 1.3, which was a good thing.17:48
natefinchjw4: it was something about our version of deep equals needing a different implementation in 1.4 or something...  not actually a test failing, but something in our test frameworks not working correctly.  IIRC Rogpeppe was the one who wrote the code17:52
jw4natefinch: I see.  I'm guessing we're not moving to 1.4 (or later) until our next LTS version of Ubuntu?17:53
natefinchjw4: or until it gets backported to Trusty.  I'm not 100% certainly on all the ins and outs of Ubuntu packaging... but yes, Ubuntu is the limiting factor in one way or another17:54
jw4natefinch: cool17:55
voidspaceare we still blocked?18:17
jw4voidspace: yep18:21
jw4voidspace: http://goo.gl/4zd1e9 (shortened because the original is so long)18:22
voidspacejw4: thanks18:24
voidspacejw4: I've saved the bookmark this time :-)18:24
voidspaceright, g'night all18:45
voidspacesee you tomorrow18:45
wwitzel3fwereade: ping18:47
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
thumpersinzui: ci status?20:07
sinzuithumper, We think we have a working rev.20:07
thumpersinzui: seems that both critical bugs are fix committed20:07
sinzuithumper, we are retesting to show that we didn't get lucky20:07
katcothumper: hey thank you for reviewing my branch20:08
thumperkatco: np, was a mix of RB and github reviews, as the github diff handles moves much better20:09
katcothumper: oh... i didn't even check gh; do i need to look there, or you were just using that as a tool?20:09
thumperkatco: no, all comments are on rb20:09
katcothumper: ah cool20:10
katcothumper: thanks for aggregating them for me. i responded to all of your comments. please lmk if you disagree with anything (few questions in there too)20:11
menn0sinzui: your comments on bug 1401130 indicate that the problem isn't fixed yet. is that right?20:17
mupBug #1401130: Joyent instances sometimes can't communicate via the internal network <ci> <joyent-provider> <regression> <juju-core:Fix Committed by hduran-8> <juju-core 1.21:In Progress by menno.smits> <https://launchpad.net/bugs/1401130>20:17
sinzuimenn0, don't panic20:17
sinzuimenn0, The bug has always been about 1.20 and beta4 pass, alpah1 does not. 1.20 was failing about the time of the ci tests.20:17
sinzuimenn0, perrito666 and i have been doing repetitive deploys with 1.20, beta4, and  alpha1. We have no failures for beta4, 1 failure for 1.20, and *no* failures for alpha1 so far. I and starting the last test to remove the regressions20:19
perrito666sinzui: tx20:20
menn0sinzui: ok20:20
menn0sinzui, perrito666:  has the joyent routing fix been backported to 1.21?20:20
sinzuimenn0, no, 1.21 never failed the tests20:21
perrito666menn0: not that I am aware of it20:21
sinzuimenn0, I am not against backporting. I want dimiter's backport first though20:21
menn0sinzui: the routing fix is tiny and will be trivial to backport20:23
sinzuimenn0, okay, thank you20:23
perrito666+1 to menn0 backporting his fix one cannot always be too sure20:23
menn0sinzui: I really do think that it's just luck that 1.21 has been passing20:23
menn0sinzui: master hasn't been passing because of that and this other issue20:24
menn0sinzui: where the deploy command fails20:24
sinzuimenn0, menn0 Its been a good streak given the number of bundles and release tests we did during the last two weeks20:24
menn0sinzui: indeed. that I can't quite understand given how easily I ran into the problem with 1.21 when testing manually20:25
menn0sinzui: I've been meaning to ask... with these deploy tests it looks like the Juju binary is pulled from a deb created elsewhere (I presume another jenkins job)20:26
menn0sinzui: how sure can we be that the deb matches the rev we think we're testing?20:27
=== kadams54 is now known as kadams54-away
sinzuimenn0, if you expand the listing of successes, you can see joyent has been partularly bad recent http://juju-ci.vapour.ws:8080/view/Cloud%20Health/job/test-cloud-joyent/20:28
sinzuimenn0, The cloud jobs require a binary built by the publishing job. Each job downloads the deb that matches the hosts arch. many machines don't have juju installed. those that do can only have juju stable, and the log of the test would show the wrong version during bootstrap20:30
sinzuimenn0, you can see that the when destroy-env fails, we fallback to the stable juju to call destroy-environment --force20:31
menn0sinzui: ok20:31
menn0sinzui: my concern is that the tests pull the "last successful" build for the arch from revision-publish but how does the job know what revision that build was built from and whether it matches what the deploy test thinks it's testing?20:32
menn0sinzui: I'm not saying it doesn't work. I would just like to understand how it works :)20:33
sinzuimeno Those job cannot run of publish-revision fails. CI exits early and the other jobs are all left in pending20:34
sinzuimenn0, CI has a requirements chain. Jenkin's crap UI corrupts this stanza, which is the configuration of the job20:36
sinzuigroup-name: tests20:36
sinzuirequires: publish-revision20:36
sinzuifailure-threshold: 220:36
sinzuivote: true20:36
sinzuitags: subjects=substrate,CPC function=deploy substrate=joyent arch=amd64 series=precise20:36
menn0right, got it. so it's ci-director plugin that does the dependencies between jobs. I hadn't noticed that stuff before.20:38
menn0sinzui: thanks for the explanation20:39
rick_h_thumper: ping20:39
natefinchericsnow, wwitzel3: can you guys update this doc with how things are going?20:46
wwitzel3natefinch: what doc?20:47
ericsnownatefinch: can't edit20:49
natefinchericsnow: reload20:49
ericsnownatefinch: updated20:52
natefinchericsnow: thanks.  Obviously feel free to edit bullet points to fit whatever the actual tasks are etc.  Just want that doc to be up to date since The Powers That Be are looking at it (and I just realized I'd never shown it to you and Wayne ;)20:53
ericsnownatefinch: got it20:53
=== ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1402826
sinzuinatefinch, thumper I think CI will bless master, but abentley found a regression when in the new weekly tests we added. We need someone look look into bug 140282621:23
mupBug #1402826: 1.21 cannot "add-machine lxc" to 1.18.1 <add-machine> <ci> <lxc> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1402826>21:23
menn0sinzui: the joyent routing fix is now backported to 1.2121:50
thumpersinzui: hmm...21:50
menn0sinzui: should I also backport to 1.20? (will there be more 1.20 releases?)21:51
thumpermenn0: what do you know about the networker job?21:51
sinzuimenn0, I never want to do a 1.20 release again.21:51
menn0thumper: very little21:51
sinzuimenn0, I hope 1.21 is the new stable soon21:51
thumpersinzui: to we expect to be able to have 1.21 talk to 1.18?21:51
thumperhow can we work out the version of the server?21:52
thumperI suppose we can go "environment get agent-version21:52
thumperomg that is hacky21:52
thumperbut probably necessary21:52
menn0thumper: why do you ask about the networker?21:53
thumperbug 140282621:53
mupBug #1402826: 1.21 cannot "add-machine lxc" to 1.18.1 <add-machine> <ci> <lxc> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1402826>21:53
thumpermenn0: but it is a different issue21:53
menn0thumper: looking at that bug21:59
menn0thumper: if the error about JobManageNetworking not existing is returned could the client try again without it?22:00
thumperthat could work but is also hacky22:00
menn0thumper: agreed22:00
menn0thumper: but is capability based instead of hardcoding versions22:01
* thumper nods22:01
menn0thumper: either way works though22:02
menn0thumper: are you looking at that one?22:07
thumpermenn0: can you? I'm otp22:08
menn0thumper: ok ... another day another CI blocker...22:08
lazyPowerheyyyyyy thumper22:20
mbruzekhello thumper22:20
lazyPowerwhere are you guys stashing the lxc downloads these days?22:20
lazyPoweri have a feeling i've got a cached lxc image, and i've wiped all my templates22:20
lazyPowerhowever - watching my process list i only see gzip -d pop up, not the wget22:21
* thumper hides behind the call he is on22:21
* lazyPower snaps22:21
lazyPoweraint nobody got time for that22:21
mbruzekthumper: all my machines are in pending and I wiped out /var/lib/juju/containers/*22:21
mbruzekthumper: can you ping me after your call22:40
josethumper: hey, I'm having some problems with local, lxc is stuck in pending22:40
thumpermbruzek, jose, lazyPower: off the call now and here to attempt to answer your lxc questions22:50
lazyPowerthumper: you've got brilliant timing22:50
lazyPowerthumper: ready for the awesomeness? it was UFW22:50
lazyPoweryeah UFW managed to block the agent => stateserver communication22:50
thumperwhat is UFW?22:50
lazyPowerits a firewall22:51
josesupposed to be uncomplicated22:51
lazyPowerthe complicated uncomplicated fire wall22:51
lazyPowerso, nothing moved, nothing to blame juju core about22:51
thumperoh good22:51
lazyPowerthumper: what ports would i open in a firewall for the stateserver?22:53
thumperlazyPower: the apiserver port22:53
thumperand ssh22:53
thumperand any port opened by a service deployed to it22:53
thumperlazyPower: if you are doing HA then there are probably other state ports needed too22:54
thumperlazyPower: in order for the mongo dbs to sync22:54
lazyPowerthumper: just local, non ha22:54
lazyPower17017 is the default stateserver port correct?22:54
thumperI wish I had a week to hack to do what I liked22:54
thumperthen I'd fix the local provider22:54
lazyPoweryouv'e got 2 weeks coming up22:54
thumperlazyPower: hahaha22:54
thumperI have a busy personal project for those22:55
lazyPowerdont we all :P22:55
lazyPoweri'm going to tackle my basement22:55
lazyPowerallright, thanks for humoring me thumper all the same22:55
* jose has left #juju-dev (part)22:55
menn0wallyworld, thumper: fix for the current CI blocker. https://github.com/juju/juju/pull/131923:24
thumpermenn0: looks good, I think it needs to be in 1.21 too23:34
thumpermenn0: and thanks23:34
wallyworldmenn0: i am currently looking - i have a suggestion i'm part way through writing23:35
menn0menn0: yep was planning on backporting once the PR for master got the green light. i suspect it won't be a straightforward cherry pick because the machine command been refactored recently.23:36
menn0thumper: urgh... ^^^ this was for you.23:36
menn0wallyworld: no probs. I will wait.23:37
wallyworldthumper: menn0: i wonder, instead of looking at agent version, should we not query the state server for the jobs it has and use that as the determiner?23:37
menn0wallyworld: is that really sensible though?23:38
menn0wallyworld: just because the state server doesn't have JobManageNetworking doesn't mean the new machine can't23:38
menn0wallyworld: (not that I'm completely sure about this)23:39
wallyworldnot sure, i'd have to check in more detail. i thought that state server would have manage network job23:39
wallyworldif it doesn't then suggestion is moot23:39
wallyworldversiob check is probably ok23:39
thumperwallyworld: we don't have the facility to ask the machine what jobs it has23:39
wallyworldi just generically prefer checks based on capability rather thaN VERSION23:39
thumperwallyworld: unless you are the machine agent23:39
thumperthe client doesn't23:40
thumperwallyworld: understood23:40
wallyworldfair enough, was just thinking out loud23:40
menn0wallyworld: I prefer capability based checks too23:40
wallyworldmy real suggestion was to make the get server version method a base method on EnvCommand23:40
menn0wallyworld: but I don't think it works in this case23:40
menn0wallyworld: sure, moving the method to EnvCommand probably makes sense23:41
menn0wallyworld: you're thinking we'll have more of these things come up?23:41
wallyworldcould do23:41
wallyworldi think we may well, but of course am not sure23:42
wallyworldseems plausible though23:42
menn0wallyworld: ok, i'll move it23:42
wallyworldthanks, seems like the bestter place for it23:42
menn0LOL! bestter23:53

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!