mupBug #1447390 was opened: mongo tools missing on centos <juju-core:New> <https://launchpad.net/bugs/1447390>00:12
mupBug #1447392 was opened: ssh args list too long when bootstrapping <juju-core:New for bteleaga> <https://launchpad.net/bugs/1447392>00:12
wallyworld_thumper: you around?01:05
perrito666wallyworld: http://reviews.vapour.ws/r/1472/03:16
wallyworldty, will look real soon03:17
perrito666wallyworld: pushing a cleaner branch now that one got some odd merges from master03:24
* perrito666 wonders if rb will cope with it03:24
perrito666it did and it fits one page03:25
perrito666k its midnight I am out cheers03:25
jamwwitzel3: ping04:27
mupBug #1447446 was opened: 1.23.1: bootstrap failure, vivid, local provider <landscape> <juju-core:New> <https://launchpad.net/bugs/1447446>05:07
wallyworldthumper: you around?05:12
=== urulama|afk is now known as urulama
wallyworldjam: you have a few minutes?06:15
jamwallyworld: sure06:16
jamwhat's up ?06:16
wallyworldjam: need someone to tell me i'm an idiot, can you join say the TL hangout06:16
=== mgz is now known as mgz_
=== liam_ is now known as Guest58476
mgzwallyworld: still up?09:05
mgzjam: poké09:30
mgzjam: <http://reviews.vapour.ws/r/1470/> 'm not being unreasonable right?09:31
=== urulama is now known as urulama|lunch
wallyworldmgz: sorry, was at soccer10:57
mgzwallyworld: no problem, sending email with update10:58
perrito666wallyworld: we really need a video of you playing socker11:02
wallyworldperrito666: no we don't :-)11:02
perrito666for... negotiation purposes11:02
mgzokay, I'm having lunch now, see email/review for init woes11:03
wwitzel3jam: pong12:02
=== urulama|lunch is now known as urulama
tasdomashi, could somebody take a look at http://reviews.vapour.ws/r/1116/ ?12:36
=== mwenning is now known as mwenning-wfh
mupBug #1447595 was opened: TestLeadership fails on windows test slave <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1447595>13:21
=== liam_ is now known as Guest34021
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
mgzbogdanteleaga: when proposing crazy mps some more explaination on *why* changing the whitespace fixes the issue would be helpful :)13:41
mgzand what the issue is, for that matter13:41
bogdanteleagamgz: I accidentally discovered bash doesn't like the script with the old whitespace formatting13:55
bogdanteleagamgz: I'll edit the message, sure13:56
katconatefinch: ericsnow: stand up14:02
=== urulama is now known as urulama__
mgzbogdanteleaga: see, that does sound fun, I want the whole story in the mp :)14:04
mgz(also, I think there's an associated lp bug?)14:04
bogdanteleagamgz: :)14:08
bogdanteleagamgz: there's no bug for this one14:08
bogdanteleagamgz: but it would be nice to get it in along with the bugfix14:08
natefinchericsnow: are you looking at https://bugs.launchpad.net/juju-core/+bug/1447446 ?  Or are you working on something else?15:31
mupBug #1447446: 1.23.1: bootstrap failure, vivid, local provider <landscape> <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1447446>15:31
ericsnownatefinch: yep (forgot to assign it to me)15:31
natefinchericsnow: cool15:31
katcoericsnow: please add that to the kanban as well15:51
ericsnowkatco: will do15:51
katcoericsnow: ty sir15:51
katcoericsnow: pro tip: you can just paste the bug ID in the "card id" field of the card, and it will auto link everything15:54
ericsnowkatco: yeah, just noticed :)15:55
lazyPoweris this something awesome you have setup or is this auto-behavior?15:55
katcolazyPower: it's board specific15:55
katcolazyPower: the board owner must set it up15:55
lazyPowerah, we have an intermediary service we're routing through to get the functionality15:55
lazyPoweri can see wher this works for your team as juju-core is one project15:56
lazyPowerwe're tracking across ~ 8 billion (give or take a few billion)15:56
ericsnowlazyPower: we scored a good lead with katco :)15:56
lazyPowerericsnow: she's prettttyyy cool, i'll admit.15:56
* lazyPower hands katco a gold star15:56
ericsnownatefinch was good too :)15:57
* katco spends the next five minutes trying to press the star onto her nose15:57
ericsnowkatco: doesn't it go on your belly (or was that 2 stars)15:57
* katco is a bit lost there15:58
ericsnowkatco: Dr. Suess (star belly sneeches)15:58
katcomy daughter hasn't reached the age where i'm back up on Dr. S yet :p15:59
natefinchericsnow: katco is 1000x as organized as I was.  I think we16:08
natefinchwe'll be a lot more successful with her leading :)16:08
ericsnownatefinch: :)16:08
* perrito666 imagines moonstone conquering countries and taking power16:10
katcoemacs will be mandatory.16:11
katcowhich will lead to us being overthrown eventually16:11
* perrito666 starts a preemtive revolution16:11
katcobut it will be beautiful and terrifying while it lasts16:11
wwitzel3perrito666: are you working on that issue with maas?16:15
perrito666wwitzel3: bogdanteleaga is16:15
bogdanteleagathere's a fix waiting for review, feel free to try it out in the meantime16:16
sinzuinatefinch, I will now bug you less.16:26
* natefinch notes that katco will probably now bug him a lot more, though ;)16:28
=== redelmann is now known as rudi|bullingcomi
=== rudi|bullingcomi is now known as rudi|bullingfood
katcoericsnow: natefinch: it's certainly not hurting anything, but for now, don't feel the need to put points to bugs. if it makes you happy, please continue :)16:36
natefinchkatco: yeah, I meant to ask about that.16:38
katconatefinch: i think we'll only need to point planned feature work16:39
natefinchkatco: fair enough16:40
natefinchkatco: maybe we should actively not put points on bugs, so we don't screw with our velocity?16:40
=== kadams54 is now known as kadams54-away
katconatefinch: i'm really flexible... i think the reporting can sift that out16:41
=== kadams54-away is now known as kadams54
wwitzel3alexisb: ping17:31
alexisbwwitzel3, omy17:32
=== liam_ is now known as Guest7885
ericsnowwhat's our restriction on Go version?18:02
ericsnowlooks like the patch for the vmware provider relies on Go 1.3 features18:02
ericsnow(or rather struct fields that don't exist in 1.3)18:03
katcowwitzel3: ericsnow: core meeting18:03
=== rudi|bullingfood is now known as redelmann
natefinchgsamfira: you around?19:05
natefinchahh crap, I forgot the uniter tests are an annoyingly monolithic table driven test19:11
perrito666:D yes they are19:12
natefinchfwereade: what's wrong with this line? runCommands{`if [ $(is-leader) != "False" ]; then exit -1; fi`},19:27
natefinchfwereade: to be more specific, what happens when that test runs on windows? :P19:28
perrito666the fact that is a bash ugly oneliner19:29
* fwereade did something bashy again? sorry :(19:29
natefinchfwereade: or you committed someone else's work so you get blamed for it ;)19:29
fwereadenatefinch, nah, that was me19:29
natefinchfwereade: I'm looking to fix https://bugs.launchpad.net/juju-core/+bug/144687119:30
mupBug #1446871: Unit hooks fail on windows if PATH is uppercase <ci> <hooks> <windows> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1446871>19:30
natefinchfwereade: but when I went to run the tests on windows, saw some other failures too19:30
fwereadenatefinch, I guess it should have different constants in util_*_test.go19:31
natefinchfwereade: it would be a lot easier to understand how to fix it if I didn't need to parse a 1600 line DSL first :/    Last time I had to fix a uniter test it took me like 3 days for a relatively simple fix :/19:34
fwereadenatefinch, which is why I've pulled so much of it out into separate packages with things resembling actual unit tests19:34
natefinchfwereade: didn't realize you were doing that.  I hugely appreciate that.19:35
katconatefinch: the most succinct way to state why table tests should be used sparingly is: you are defining your own test runner which has a very small sub-set of its larger test runner.19:35
katcowhy that is bad should be pretty obvious19:35
katcosorry, very small sub-set of features of its larger test runner19:36
fwereadenatefinch, that bug looks like it should be reasonably possible to repro it in unit tests somewhere in uniter/runner19:36
natefinchkatco: ironically, we're already one more level deep using gocheck19:36
katcobut at least gocheck is a proper test runner19:36
perrito666katco: anyone against your argument should be forced to change the current accepted values for statuses :p it is much like a domino castle19:37
fwereadenatefinch, ...which remains less well tested than I would like, but *should* have some explicit tests for the env-var population bits19:37
katcoperrito666: i had to touch that code once and wowwwww19:38
perrito666katco: it took me five minutes to change the values and validators and setters.. and 4 days to fix that test19:39
katcoperrito666: yeah exactly my experience19:40
natefinchfwereade: so I'm just trying to get the tests to actually run on windows and then I'll tackle the env casing problem... is there not some more simple way to verify that the hook tool isn't there, rather than sending a command-line for the uniter to run?  Yes, we could make one that runs on windows and one on linux... but that still seems like the most complicated way to test if a file exists on disk.19:48
fwereadenatefinch, well, those tests are the effectively the functional tests for the uniter19:49
fwereadenatefinch, you should be able to write a test case in uniter/runner that exposes the problem, though19:49
fwereadenatefinch, env.go19:50
fwereadenatefinch, ha:19:50
fwereade    if runtime.GOOS == "windows" {19:50
fwereade        c.Skip("bug 1403084: There are some problems regarding os.Environ() on windows")19:50
fwereade    }19:50
mupBug #1403084: Tests that need to be fixed on windows <ci> <tech-debt> <testing> <windows> <juju-core:Fix Released> <https://launchpad.net/bugs/1403084>19:50
fwereadenatefinch, so I'd start there, I think19:50
=== kadams54 is now known as kadams54-away
natefinchfwereade: ok19:51
fwereadenatefinch, I know there's a bit of jiggery-pokery regarding env vars for windows -- we were doing <something> twice in some circumstances, and I distorted the code a bit to make sure we only did it once19:51
fwereadenatefinch, so there is another path you need to check somewhere to make sure it works in some weird context (juju-run, or debug-hooks, or something)19:53
bogdanteleagaiirc that test was skipped because os.Environ() introduced some flaky variables, but it should not affect anything else19:54
fwereadenatefinch, at a guess the problem is env.go:54?19:54
fwereade        "Path=" + paths.GetToolsDir() + ";" + os.Getenv("Path"),19:54
fwereadenatefinch, a few extra tests similar to TestEnvWindows should pick it up, I think?19:55
fwereadenatefinch, although you should figure out what happens when you've got path and PATH and Path all defined -- presumably the `Path` we write is lower priority than whichever one's already set in problematic situations?19:56
fwereadenatefinch, regardless, you shouldn't need to touch the giant uniter functional tests just for that fix, so long as you can demonstrate it in the unit tests19:57
bogdanteleagaactually, since I don't get the juju-log.exe not found on my machine, the env_test.go might reveal the issues on the problematic machines19:57
natefinchfwereade:  The uniter tests don't pass on windows right now.  That's part of that bug.19:58
natefinchfwereade: unrelated to the environment variables19:58
fwereadenatefinch, ok, and they should; but the bug has "Any windows machine with casing of the path variable other than 'Path' will fail to find hook tools."20:00
mgz_bogdanteleaga: thanks!20:00
=== mgz_ is now known as mgz
natefinchfwereade: yes, I know.  I'm just trying to get the tests to a point where they only fail for that reason, then I can fix that reason20:01
bogdanteleaganatefinch: I think it's only env issues at this point20:01
bogdanteleaganatefinch: it complains about not finding juju-log.exe at some point20:02
bogdanteleaganatefinch: after executing it moments before20:02
mgzbogdanteleaga: assign bug 1447595 to yourself :)20:03
mupBug #1447595: TestLeadership fails on windows test slave <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1447595>20:03
fwereadenatefinch, I submit that you will have an easier time of it if you repro and address the path issue in isolation20:03
fwereadenatefinch, lest you get caught in a morass of other unexpected problems with the uniter test on windows20:03
bogdanteleagamgz: done20:04
bogdanteleagahttp://reviews.vapour.ws/r/1477/ anybody in for a fast review?20:04
mgzbogdanteleaga: lgtmed20:04
fwereadenatefinch, I don't know what they might be but I'm not so optimistic as to assume the path issue is the only obstacle20:04
fwereadebogdanteleaga, I don't see where it's successfully executing juju-log.exe?20:06
bogdanteleagafwereade: on install it executes, on config-changed it says not found20:06
bogdanteleagafwereade: http://data.vapour.ws/juju-ci/products/version-2549/run-unit-tests-win2012-amd64/build-276/consoleText20:07
bogdanteleagafwereade: second test20:07
mgzbe a bit wary of that log, it would be one with both PATH and Path set in the environment block, which could well do weird things20:10
fwereadebogdanteleaga, ...I see20:11
natefinchhuh, interesting, for some reason go test's  -test.foo style flags don't work in powershell20:11
fwereadebogdanteleaga, well, that's exciting20:11
mgzbasically we just need a helper in utils that handles this correctly that both utils/exec and the uniter can use20:11
bogdanteleagamgz: afaik, I can't merge it so you can do it if you want to20:11
fwereademgz, yeah, PrependToPath or something20:11
bogdanteleagathey pass for me on both win8 and win server so I can't really reproduce this one20:12
fwereademgz, I am somewhat convinced that we could come up with a happier arrangement of utils/exec so we didn't have that func cloned in both places20:12
mgzfwereade: indeed20:13
fwereadebogdanteleaga, can you try changing the env we set up in the tests? just tweak the value in env_test.go:125 and see what you get20:13
bogdanteleagabut the juju-log.exe thing has been there for a while, did you have both set up for a long time?20:13
mgzbogdanteleaga: $$merge$$ requested - I'll look at your other branches again later if I get a mo20:14
bogdanteleagacool, they're just as small :)20:14
mgzthe other complication I didn't call out in the bug - the go behaviour of os.Getenv on windows changes20:14
mgzit's exact case in 1.2 but uses windows api in I think 1.3 and that will retrieve Path if you ask for PATH and visa versa20:15
bogdanteleaganow that's fun20:15
mgzI had the intention of getting to fix this some point this week... but many things have intervened. I'll happily throw peanuts at nate though :)20:17
natefinchI like peanuts :)20:18
bogdanteleagafwereade: http://paste.ubuntu.com/10873918/ not sure what you're looking for20:19
fwereadebogdanteleaga, I was thinking more about s/Path/PATH/ than s/bar/obar/?20:20
fwereadeand, well, it'll fail for sure, but it might fail in an interesting and instructive way... for someone running the right version of go... possibly on a suitably idiosyncratic windows box20:21
bogdanteleagafwereade: sounds like quite the setup20:22
fwereadebogdanteleaga, yeah, I guess it takes some proper investigation20:23
bogdanteleagamgz: looks like it crashed, not sure why though20:25
mgzhm, godeps failed, 'unrecognized import path "gopkg.in/natefinch/lumberjack.v2"'20:27
mgzdid someone delete nate?20:27
natefinchmgz: better not have20:31
natefinchmgz: works for me20:32
natefinchmgz: godeps and go get20:32
mgznatefinch: likely something intermittent and networky20:33
natefinchmgz: could be a bad HTTP response from gopkg.in confused it20:33
mgzI'll remerge and see20:33
bogdanteleagafwereade: changing it to PATH doesn't make it fail :)20:34
bogdanteleagamgz: that's what I get for pushing from windows with no prepush hook. can you try again?20:43
fwereadeanyone for a *really* trivial review? http://reviews.vapour.ws/r/1478/diff/20:43
natefinchfwereade: ship it!20:45
fwereadenatefinch, cheers20:45
mgzbogdanteleaga: sad gofmt :) regoing20:47
natefinchfwereade, mgz, bogdanteleaga:  for the record, doing sets and gets in a simple program, I can't get setenv and getenv to act incorrectly on 1.2.2 .... get always seems case insensitive20:57
natefinch(on windows)20:57
mgzokay, maybe that bug report was wrong, good good20:58
bogdanteleagafor me os.Environ() returns =ExitCode= in the environment on win2012r220:58
natefinch(sorry, get and set are both case insensitive)20:58
mgzso, it's just the use of os.Environ() that's particularly suspect20:58
natefinchmgz: probably just our use of os.Environ.... we probably expect it to be case sensitive, and it's not20:59
mgzwell, it's case-preserving21:00
mgzyou just can't do straight string matches vs things you've pulled out previously with os.Getenviron21:01
natefinchgotta run, talk later.21:01
mgzlater nater21:01
fwereadeI have an even simpler review: http://reviews.vapour.ws/r/1479/21:08
fwereadethe description is noticeably larger than the change21:08
fwereademenn0, good morning, can I hit you up for a review or 2?21:26
fwereademenn0, http://reviews.vapour.ws/r/1479/ is genuinely trivial21:26
menn0fwereade: sure21:26
fwereademenn0, and http://reviews.vapour.ws/r/1224/ is less so, but I think and hope it's well-commented and documented, and has been used in anger in enough pending CLs, that I think it should be good21:27
fwereadetasdomas, ...unless you're around and want to celebrate your graduation by upgrading your I-think-it-makes-sense to and LGTM? ;p21:28
menn0fwereade: I'll take a look21:30
=== kadams54-away is now known as kadams54
menn0fwereade: sorry, just dropped out (keyboard problems, stuck capslock)21:39
menn0fwereade: looking now21:39
fwereademenn0, no worries :)21:40
alexisbso menn0 fair warning, critical interrupt headed your way21:42
fwereademenn0, then definitely don't worry about 122421:43
menn0alexisb: ok... a critical bug fix?21:44
alexisbmenn0, yes, maybe you and fwereade can have a critical bug party :)21:44
alexisbwallyworld, has the details21:44
menn0fwereade: ship it for 147921:48
menn0fwereade: it wasn't immediately obvious why it fixes the problem but after a bit of digging I think I get it21:49
menn0fwereade: at any rate, it's a more straightforward way of getting the job done21:49
fwereademenn0, indeed21:49
=== kadams54 is now known as kadams54-away
fwereademenn0, glad it passes a sniff test though, I lost much of the detailed context by not extracting it immediately21:50
menn0fwereade: just looking at 1224 now. i'm glad that you've been looking at this. the way works are started and managed has become a mess.21:51
menn0workers even21:52
fwereademenn0, yeah21:52
fwereademenn0, I am currently rather quailing at the prospect of fixing the machine agent21:52
fwereademenn0, the unit agent was hard enough21:52
fwereademenn0, but I've had some practice now :)21:52
wallyworldmenn0: did you have a moment to chat? maybe in the onyx standup hangout?22:01
menn0wallyworld: sure. give me a minute.22:02
mgz...do I send my daily dose of good news to the mailing list?22:21
mgz"hey everyone, have these orrible breaking bugs to play with..."22:21
menn0fwereade: are you still around? one of the bugs i'm looking at now might be related to recent uniter changes22:22
menn0jw4: ping/22:24
jw4menn0: ola22:24
menn0jw4: you've been looking at bug 143848922:24
mupBug #1438489: juju stop responding after juju-upgrade <upgrade-juju> <juju-core:In Progress by johnweldon4> <juju-core 1.23:Triaged by johnweldon4> <https://launchpad.net/bugs/1438489>22:24
menn0jw4: where are things at right now?22:25
jw4menn0: yes, I'm afraid I'm responsible for that one22:25
jw4menn0: I think the cleanest might be to back out my hook changes from a few weeks ago22:25
mgzmenn0: see also https://chinstrap.canonical.com/~gz/ for that, some logs and things that may be of interest22:25
menn0jw4: what's the PR with your hook changes?22:26
jw4menn0: let me find it22:26
menn0mgz: thanks22:27
jw4menn0:  https://github.com/juju/juju/pull/189722:28
jw4menn0: I'd prefer to fix it though rather than backing it out22:29
jw4menn0: I haven't figured out why the hooks quit firing after the upgrade - I just assumed it was because of those changes of mine22:30
menn0jw4: shall I take a look?22:31
menn0agreed that fixing is preferrable to backing out if possible22:31
jw4menn0: feel free - the repo is easy22:31
jw4all I did to reproduce was to install 1.22, install charm, upgrade to 1.23, observe that hooks quit firing22:32
menn0jw4: cool22:33
jw4menn0: mgz just added a simple repro step to the bug22:33
menn0jw4: what about the recent attempts to fix this? should they stay or be pulled?22:33
menn0jw4: PRs 2067 and 205822:34
mgzmenn0: if I understand correctly, the earlier landing was just making trying to make the error not as fatal, didn't change the upgrade step itself22:34
jw4menn0: the other fixes are actually valid...22:34
menn0jw4: ok. just confirming.22:34
jw4mgz: menn0 yeah.. actually this upgrade issue shouldn't be related to the upgrade steps22:34
jw4more likely that it's related to the uniter logic itself that changed, if indeed it was caused by my original PR22:35
menn0jw4: what about the errors related to not being able to read the uniter state?22:36
jw4(the upgrade steps are effectively a no-op, because of a misunderstanding in how upgrades were handled)22:36
mgzthis is one of those kinda-shoulda just backed out in response to the bug cases, but the fact we weren't yelling because our upgrade job passed let it slip22:36
jw4menn0: that was because of tightened validation logic.  Since the upgrade steps actually didn't work it was reverted to what was originally there22:37
jw4mgz: yeah... however, I haven't established yet that the hooks not firing is a result of the original PR, but it sure looks suspicious22:38
menn0jw4, mgz: ok well let me run with it for a bit and see what I find22:39
jw4menn0, mgz originally this bug was about the uniter getting into a validation error loop, but now we're past that because of the other fixes, and now we're encountering this issue with hooks not firing22:39
menn0jw4: understood, thanks22:40
* jw4 needs to drop off to take son to drum lessons... bbl22:40
menn0jw4: np, talk to you later22:41
menn0mgz: do we still have a problem with upgrades to 1.23 as well?22:41
menn0mgz: or is it just 1.24 at this stage?22:42
mgzmenn0: the critical part is the upgrade path from 1.22 to 1.23, which exhibits this bug22:42
mgzI've not seperately tested 1.23 to 1.24 but the next CI run of a trunk branch will do that for us.22:42
menn0mgz: ok, i'll focus on the upgrade to 1.23 to start22:43
mupBug #1447841 was opened: eu-central-1 AWS region V4 signing required and not supported <juju-core:New> <https://launchpad.net/bugs/1447841>22:52
mupBug #1447841 changed: eu-central-1 AWS region V4 signing required and not supported <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1447841>23:04
menn0mgz: I think I see the problem. just trying to confirm now.23:06
mgzmenn0: ace23:07
menn0mgz: but wallyworld needs something reviewed first23:07
mgzcircular favours! I have a branch I'd like wallyworld to review (it's not urgent though :)23:08
wallyworldi'll get to it soon23:09
mupBug #1447841 was opened: eu-central-1 AWS region V4 signing required and not supported <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1447841>23:19
wallyworldmgz: why is Shutoff considered to be alive?23:26
mgzwallyworld: I presume because it's fine if you then manually nova start it, want be to dig up the change it was added in?23:29
mgzwallyworld: I also wanted to allow BUILD(anything) but was scared we actually depend on the machine to be in a somewhat usable state elsewhere23:30
wallyworldmgz: i ask because the behaviour is being changed from active | build and i'm not sure we want to do that23:30
mgzwallyworld: bug 138270923:31
mupBug #1382709: Openstack provider, Instance-state doesn't change on instance shutdown <cts> <cts-cloud-review> <status> <ubuntu-openstack> <juju-core:Fix Released by dimitern> <juju-core 1.21:Fix Released by wallyworld> <https://launchpad.net/bugs/1382709>23:31
mgzwallyworld: ah, in AllInstances? that is actually dead code, I probably should have left alone23:31
wallyworldyeah, in AllInstances23:32
wallyworldyou saying we don't call that anymore?23:32
mgzno usage of a provider in the juju codebase ever calls AllInstances23:32
mgzit's just part of the provider api :)23:32
wallyworldmgz: nah, it's called in bootstrap23:32
wallyworldand AllInstances should be a superset of Instances23:33
wallyworldso i'm worried about changing that23:33
wallyworldoh, right, i read the bug. doing stuff out of band we seem to be23:35
mgzhm, so it is, somewhat oodly23:36
mgzwallyworld: anyway, change just makes it more like the Instances() call so finds more stuff23:37
wallyworldyeah, fair enough23:37
mgzwallyworld: I'm not sure on the logging I added23:37
mgzI want some ammount more, but not completely sure on the balance between useful debugging and spam23:38
wallyworldmake  it trace perhaps23:38
mgzwallyworld: that AllInstances call in bootstrap is new, and puzzling...23:40
mgzwell, new, 2014... new since I looked at that code23:41
wallyworldi can't recall the specifics23:41
wallyworldmgz: i'm not comfortable about landing this without tests - the goose test service should be updated to match23:42
wallyworldprovider/cloudsigma/config.go:97: no formatting directive in Errorf call23:43
wallyworldwhy was stuff landed when there was a govet error23:43
wallyworldi thought we rejected such things now23:43
wallyworldmgz: ?23:43
mgzwallyworld: hm, is that still not fataled in the check script? I thought that had been flipped23:44
wallyworldmgz: me too, but i just pulled master23:44
wallyworldand now get that error23:44
mgz./scripts/verify.bash; echo $?23:45
ericsnowcould someone spare we a review on a small patch: https://github.com/juju/govmomi/pull/123:46
jw4menn0: you figured it out?23:47
menn0jw4: still reviewing wallyworld's change. almost done.23:48
jw4ah. kk23:48
menn0jw4: but what i think is happening is that the upgrade step runs while the machine agent is upgrading23:48
menn0jw4: but at that point the unit agent is still running the previous juju version23:49
menn0jw4: so when the unit agent shuts down it overwrites the changes made by the upgrade step23:49
mupBug #1447846 was opened: Hooks don't fire after upgrade 1.23.0 <hooks> <regression> <upgrade-juju> <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1447846>23:49
menn0jw4: sound plausible/23:49
jw4menn0: oooh interesting.23:49
wallyworldericsnow: i'm not sure the build directives are correct. don't we just want go1.2 and !go1.223:50
jw4menn0: I don't think the hook.Info upgrade step *ever* runs, because the upgrade step is supposed to find all the units for a given machine and run the upgrade on each one manually23:51
wallyworldotherwise how would it work on go1.4 etc23:51
jw4i.e. I don't think the upgrade process automatically runs upgrade steps on units, only on machines23:51
jw4maybe I'm wrong though...23:52
menn0jw4: yeah you're right... so there's 2 problems23:52
menn0jw4: the upgrade mechanics only run on the machine agents so the check for a unit tag in the upgrade step is never going to be true23:53
jw4menn0: I backburnered my upgrade steps problem by reverting the validation logic... but how does your proposed scenario cause the hooks to stop firing after upgrade?23:54
jw4(I think it's plausible, but I'm missing the connecting steps)23:55
menn0jw4: i haven't quite figured it out either23:55
jw4menn0: kk - well I'm glad to have your eyes on it... I'm embarassed by this whole issue23:56
menn0jw4: but i'm wondering if the uniter state file hasn't been upgraded then we can end up with the "unexpected hook info with Kind Continue" error23:56
jw4menn0: yes - that error will always be logged - it's almost certainly a red herring to the real problem23:57
jw4when I 'fixed' the validation I just changed it so that instead of crashing the uniter, it just logs the problem once and then continues23:57
ericsnowwallyworld: go1.2 means Go 1.2 and later23:58
jw4so the error will always show once when the uniter starts up  (until I/we fix the upgrade steps), but it shouldn't prevent the uniter from continuing normally after that23:58
wallyworldericsnow: ah, i see, thanks23:59
menn0wallyworld: review done. for some reason RB has duplicated one of my comments for a particular section of code and I can't figure out how to fix it. please ignore the dup.23:59
wallyworldmenn0: tyvm23:59

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