huwshimithumper: Afternoon. Are you using any features from nose in jujulib?04:06
thumperno, just running tests04:06
thumperhuwshimi: as long as "make check" works, I'm happy04:07
huwshimithumper: Ah cool, I have some comments on my PR about just using pytest, so I'll fix that up if that works for you?04:07
huwshimithumper: Cool, cheers mate.04:07
mupBug #1484993 changed: TestBootstrapReusesAffinityGroupAndVNet: no tools are available for your environment <blocker> <ci> <i386> <ppc64el> <regression> <unit-tests> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1484993>06:40
dimiternfwereade, ping06:44
fwereadedimitern, pong06:44
dimiternfwereade, I'd like to ask you about a quirk with our environ constraints implementation that bit me badly06:45
dimiternfwereade, we have Tags *[]string ",omitempty" and the doc comment says if they're nil they're not set, but if they are an empty slice, they are replaced06:46
fwereadedimitern, ok06:46
dimiternfwereade, this is a lie - esp. for env constraints, as they use a single doc, so there's *no way* to set tags= once there's a value on it06:47
dimiternfwereade, the same applies to Networks and Spaces (i'm now adding)06:47
dimiternfwereade, so my question is - is it a doc issue or by design you can't unset a list-style constraint once set on an environment06:48
fwereadedimitern, that just sounds like a mistake honestly -- although, I admit, I forget the details06:49
fwereadedimitern, what happens if you just do set-constraints mem=8G, on anything -- does it not overwrite the whole set of constraints?06:49
fwereadedimitern, at that level?06:49
dimiternfwereade, so first, this only happens if you're using the same constraints document - i.e. environ constraints is an obvious case (not sure if you can do it on a machine)06:50
fwereadedimitern, ahhh -- so it's a mgo level thing? we're not doing $unset when we should?06:51
fwereadedimitern, would also apply to services, but, yeah, not machines06:51
dimiternfwereade, then, it's pretty easy to try it out - juju environment set-constraints mem=8G tags=foo,bar; then again with "mem=4G" -> you get "mem=4G tags=foo,bar"; trying with "tags=" -> same result06:51
fwereadedimitern, ...unless we get cleverer about retry-provissioning-with0different-constraints one day06:51
dimiternfwereade, it is a mongo thing indeed06:52
fwereadedimitern, right, yeah, I see -- we just $set and don't $unset everything else06:53
fwereadedimitern, dammit06:53
dimiternfwereade, so what I did to fix the failing tests for the time being - added ResetEnvironConstraints which does removeOp+createOp in export_test06:53
dimiternfwereade, we just $set06:53
dimiternfwereade, but this needs fixing I think - it's pretty surprising06:54
fwereadedimitern, I would suggest that those tests are failing because they should, and ResetEnvironConstraints is a Bad Thing06:54
fwereadedimitern, but, good catch06:54
dimiternfwereade, if the behavior is "don't touch anything I don't explicitly set" - that's great, but there needs to be a way to reset them06:54
fwereadedimitern, I'm not sure how great it is actually06:55
* fwereade thinks06:55
dimiternfwereade, they only started failing because so far there were only 2 cases where we do "set a list-constraint to empty", then "set it to not empty" - last 2 cases, any other case added after it reveals the bug06:55
dimiternfwereade, tags were totally untested in this set-env-check-inherited-repeat06:56
* fwereade glowers around in an undirected sort of way and reminds everybody that tests are critically important06:57
dimiternfwereade, I think this deserves a bug report and I'll file one06:58
fwereadedimitern, at the very least, `an empty value always means "not constrained"` and we're failing there06:59
fwereadedimitern, https://jujucharms.com/docs/devel/charms-constraints06:59
fwereadedimitern, yes please06:59
dimiternfwereade, it can be fixed easily, but the expected behavior needs to be well defined - do we unset what you don't provide implicitly? if not, how can you tell juju to do unset+set when you want?07:00
fwereadedimitern, I think we should indeed unset everything not provided07:00
dimiternfwereade, and provide a "merge existing" command?07:02
dimiternfwereade, we don't really specify that the merge-by-default is what happens, so I guess we could safely do replace-by-default, at least for environ constraints07:10
fwereadedimitern, yeah, I *think* the merging behaviour can be reasonably considered a bug07:12
fwereadedimitern, I don't think there's much reason for a merge-existing?07:12
fwereadedimitern, the inheritance is confusing enough07:12
fwereadedimitern, effectively having an extra level of it is IMO worse than assuming people know what they want to set07:13
dimiternfwereade, it's also that it only really matters for lists, as other fields usually have a non-ambiguous "empty" value07:13
dimiternfwereade, fun fact: "cpu-cores=" != "" != "cpu-cores=0"07:14
fwereadedimitern, yeah, I think we definitely want to overwrite lists rather than merge07:14
dimiternfwereade, ok, then I'll make this part of my fix07:15
fwereadedimitern, yeah, `cpu-cores=` means "fall back" where `cpu-cores=0` means "any number of cores is fine" -- right?07:15
dimiternfwereade, not quite :) - all of the cases match omitempty07:16
dimiternfwereade, but only when stored in state07:16
fwereadedimitern, wait, omitempty ignores the difference between `nil` and `new(int)`?07:17
dimiternfwereade, but e.g. (*int)(value-with-0) and (*int)(nil) are treated the same07:17
* fwereade resists the urge to render #juju-dev NSFW forever07:18
dimiternfwereade, :D07:18
* fwereade is going for a quiet rage-filled cigarette07:18
fwereadedimitern, thanks for many good catches then :)07:18
dimiternfwereade, cheers :)07:18
dimiternfwereade, env:"mem=8G", svc:"mem="; effective: "mem=" which is the same as "mem=0"07:30
dimiternso "X=" is never treated as "", but as "X=<empty-value>" instead07:38
TheMuemorning, lots of traffic on CI *lol*08:05
TheMuelarge packages w/o sub-packages lead to story-telling test function names08:21
dimiternTheMue, dooferlad, guys, will be a couple of minutes late for standup09:00
TheMuedimitern: ok09:01
* TheMue looks left09:03
* TheMue looks right09:03
TheMueI'm a poor, lonesome coder *sing*09:04
dooferladTheMue: https://plus.google.com/hangouts/_/canonical.com/juju-sapphire?authuser=0 ?09:04
TheMuedooferlad: I'm here https://plus.google.com/hangouts/_/canonical.com/juju-sapphire too. the one that has been in the reminder mail of the calendar.09:05
dooferladTheMue: we are in there too09:05
TheMuedooferlad: will reconnect09:05
fwereadeTheMue, dimitern: why are we pulling environ config down to the machine agent to figure out if we support networking?09:31
fwereadeTheMue, dimitern: shouldn't this be a job?09:32
dimiternfwereade, because we need an environs.Environ to type-assert on09:32
fwereadedimitern, I don't think there's any justification for creating an environ in an agent09:33
fwereadedimitern, we can figure that out at machine-creation time, can't we? when we've already got the state policy available?09:34
dimiternfwereade, it a different sort of job - address (de)allocation and manage networking09:36
fwereadedimitern, yeah, I'm not saying its the same as JMN -- but wouldn't it be JobAllocateAddresses or something?09:39
dimiternfwereade, yeah, I agree the best thing is to add a job09:41
dimiternfwereade, however, as a incremental improvement, we can make our tests better around checking if the environment supports address (de)allocation (which we don't have full coverage of now)09:42
dimiternfwereade, and then build on top of this by introducing a job09:42
dimiternfwereade, sane?09:42
fwereadedimitern, what I'm worried about is that this is further degradation of machine agent sanity -- it's bad enough that there are some bits of code that switch on provider type, but I'm really bothered by *new* code that actually pulls down a whole env config and tries to construct it and hopes that the foul overwrite-secrets hack doesn't cause problems09:43
fwereadedimitern, imo the machine agent shouldn't even know what sort of provider it's running on09:44
dimiternfwereade, fwiw this only happens once per environment09:47
fwereadedimitern, how does that make env-construction in the machine agent any less evil?09:48
dimiternfwereade, and we did drop one (the only remaining?) provider type checks in the MA using JobManageNetworking09:48
TheMuefwereade: how do you compare address allocation support with firewaller modes? the depend on the providers capabilities too. could a similar approach be feasable?09:48
dimiternfwereade, why is it evil for the JobManageEnviron agent?09:49
dimiternfwereade, it has full access to it anyway09:49
fwereadedimitern, the *agent* shouldn't know anything about the environ09:50
fwereadedimitern, it might run some job that knows about it09:50
fwereadedimitern, but that's a completely distinct responsibility09:50
fwereadeTheMue, I'd say that firewaller modes should not be using environ config either09:51
dimiternfwereade, by "some job that knows about it" you mean a worker that pulls the environ config on start?09:52
fwereadedimitern, yeah09:52
dimiternfwereade, even if it doesn't need it except to check whether it needs to do anything at all09:52
fwereadedimitern, via a facade, and for a worker, that's allowed to know about it09:52
fwereadedimitern, do we know why we added Environment() to the Agent facade in the first place?09:53
dimiternfwereade, not really09:53
dimiternfwereade, I assume because it was there09:53
fwereadedimitern, oh, feck, it's not even that09:54
dimiternTheMue, +1 about the firewaller09:54
fwereadedimitern, someone just thought "lol  I'll use the wrong facade in the agent"09:54
dimiternfwereade, :)09:54
dimiternfwereade, ok, can we agree to add a job later?09:55
dimiternfwereade, I promise we won't forget about it09:55
TheMuedimitern: my though is that we have more and more providers with different capabilities, so how to only start those workers (in their right modes) for the current environment?09:55
fwereadedimitern, TheMue: this all seems like code that's been added in the last couple of days though09:55
fwereadedimitern, TheMue: and should frankly have never passed review09:56
dimiternfwereade, the change is strictly an improvement over what we had before09:56
TheMue"should" is a wonderful subjunctive09:56
fwereadedimitern, TheMue: at the *very least*, why is this stuff not handled inside the addresser worker?09:57
dimiternfwereade, this check is simply for a better UX - not to spam the logs with "addresses: not starting.."09:57
TheMuefwereade: yep, agree to dimitern, the old approach always started the worker, got the events but done nothing09:57
dimiternfwereade, it used to be, but TheMue suggested it should be done at the apiserver level with a single call09:57
dimiternfwereade, and I liked the idea of not violating layers unnecessarily09:58
fwereadedimitern, TheMue: I don't see how gunking up the already-terrible agent code is an improvement over making the addresser exit quietly with a single log message when it finds it's in an inappropriate env09:58
dimiternfwereade, it is, after all, a job that requires both access to state and the provider - apiserver is the obvious place for that, isn't it?09:58
TheMuedimitern: the dont-start-not-needed-worker came later and is a different one. imho that's wht we currently talk about09:59
dimiternfwereade, it exits quietly ever 3s as it gets restarted by the runner09:59
fwereadedimitern, TheMue: wait, I hope it doesn't use state directly, does it?09:59
TheMuefwereade: nope, that has been the original idea of the change10:00
dimiternfwereade, not anymore, that was the whole point of the exercise - it uses its own apiserver facade10:00
TheMuefwereade: no more state usage10:00
fwereadeah cool :)10:00
fwereade(although... why would we *ever* have used state directly?)10:00
fwereade(we did *so much fucking work* to cut out direct state access)10:00
dimiternfwereade, because its on the JobManageEnviron MA10:01
fwereadedimitern, that dooesn't mean iit gets to see mongo10:01
dimiternfwereade, this card along with a bunch of others (some of which already landed) is our effort to cut state access for JME workers10:01
fwereadedimitern, re the 3s restart -- why don't you just *return nil*?10:02
fwereadedimitern, meaning "I have done all the work I can, don't bother me agaib"10:02
dimiternfwereade, if the runner supported a way to tell it "don't restart me anymore"10:02
dimiternfwereade, it would've been simpler10:02
dimiternfwereade, IIRC that leads to the same thing10:03
dimiternfwereade, hmm, ok fair enough10:05
TheMuefwereade: nice10:05
dimiternfwereade, so it does not restart if it return nil from the loop?10:05
fwereadedimitern, yeah10:05
dimiternfwereade, that's ok, but not good enough I'm afraid10:05
fwereadedimitern, go on10:05
dimiternfwereade, we need a way not to start it in the first place10:05
fwereadedimitern, why?10:05
TheMuefwereade: dimitern: so addresses starts, first time talks to API, get's a not supported error back, and quits nicely10:06
dimiternfwereade, i.e. a way to return something != nil from New() that tells the runner not to run it10:06
fwereadedimitern, TheMue: why can't the worker just detect that it can't do anything and stopp itself?10:06
fwereadedimitern, TheMue: it's not an error -- it has examined the world and determined that it doesn't need to do anything ever10:07
dimiternfwereade, hmm.. I guess the apiserver facade's WatchIPAddresses can return a NotSupportedf if it doesn't make sense to watch or run the worker?10:07
TheMuefwereade: it needs the environment to check this capability, so we move the question from machine.go into the addresser worker itself. that's what you meant?10:08
fwereadedimitern, TheMue: I'd prefer a sepaarate api call, rather than overloading that one10:08
dimiternfwereade, that's fine - it can be separate10:09
TheMuesounds good10:09
dimiternfwereade, what's important is will it work before the loop starts10:09
fwereadeTheMue, I *would* probably like it most if we represented it as a job, but yeah, it's definitely better to have it scoped to the addresser worker10:09
fwereadeTheMue, dimitern: although actually, yeah, maybe it *is* just part of JME10:09
fwereadeTheMue, dimitern: this may be relevant: in the unit agent, now, the manifolds themselves return dependency.ErrMissing when started in an inappropriate context10:12
fwereadeTheMue, dimitern: this means we can have nice declarative conditional-free definitions of various sets of workers and their dependencies10:13
fwereadeTheMue, dimitern: relevant/sane?10:13
TheMuefwereade: have to read tha last sentence twice10:14
fwereadeTheMue, dimitern: see cmd/jujud/agent/unit/manifolds.go10:14
TheMuefwereade: thx for the hint10:14
fwereadeTheMue, dimitern: and then the feature-flag checkinng inside worker/rsyslog and worker/logsender10:15
fwereadeTheMue, dimitern: in practice we'll only run one of those at a time I think10:15
dimiternfwereade, I like this a lot10:16
fwereadeTheMue, dimitern: but they can make that determination individually10:16
dimiternfwereade, it will also make testing this a *lot* easier10:16
fwereadedimitern, :D10:16
dimiternfwereade, one of each *per environ*10:16
fwereadedimitern, yeah, agreed10:16
fwereadedimitern, TheMue: so, to reiterate10:17
* TheMue listens10:18
dimiternfwereade, yeah, let's summarize10:18
fwereadedimitern, TheMue: I don't think we do need a separate job there, sorry for the noise on that front10:18
dimiternfwereade, in practice, no we don't10:18
fwereadedimitern, TheMue: but if we can just make the addresser (and firewaller?) check for their own validity, log once, and return no error10:19
fwereadedimitern, TheMue: then we get a slightly cleaner agent10:19
fwereadedimitern, TheMue: for relatively little in the way of code changes10:19
TheMuefwereade: dimitern: oh yes +10010:19
fwereadedimitern, TheMue: and it *also* makes my job much easier when I come to use manifolds in the machine agent10:20
fwereadedimitern, TheMue: which I am very keen to do :)10:20
TheMuefwereade: so I'm changing addresser again and you the firewaller *lol*10:20
fwereadeTheMue, if you can bear to hit both of them I would be most grateful :)10:21
dimiternTheMue, fwereade, let's not do all at once though - first the addresses, then the firewaller10:21
fwereadedimitern, yeah, that works for me10:21
dimiternaddresser even10:21
fwereadedimitern, TheMue: hopefully having done one will make the second one trivial anyeay10:21
dimiternfwereade, it should, yeah10:22
fwereadedimitern, TheMue: cool, thank you very much10:22
fwereadedimitern, TheMue: and then RB2390 becomes ~redundant, in favour of another unit test or two in each of the relevant workers10:23
dimiternfwereade, so, if I'm getting it right, you suggest to have a method in the workers' apiserver facade like CanRun()10:23
TheMuefwereade: 2390 will be dropped10:23
dimiternfwereade, which is called at the start of Handle() ? Or in the constructor returning the worker?10:23
dimiternfwereade, I'd really like it if we can avoid starting the loop if we can - i.e. constructor is better10:24
fwereadedimitern, sadly I'm not sure how we handle failing to start a worker... so it might perhaps be best to return a degenerate, already-stoppped worker from NewWorker?10:24
fwereadedimitern, little bit hackish10:24
dimiternfwereade, this assumes we have a special error like ErrCannotStart, which startWorker understands10:25
fwereadedimitern, but easily replaceable, I think, when I use manifolds10:25
fwereadedimitern, yeah, if you want to add ErrWorkerNotNeeded handling to worker.Runner, that could work10:25
fwereadedimitern, but Runner *is* a bit hairy10:25
dimiternfwereade, yeah, very much so - ok, then constructing a "degenerate" worker in this case might be better until it can be converted to use manifolds10:26
fwereadedimitern, TheMue: http://paste.ubuntu.com/12117329/10:27
fwereadedimitern, TheMue: and then for the manifolds we don't even need that10:27
TheMuedimitern: so this degenerated one has a Handle(), but that only returns I'mNotNeeded10:27
fwereadedimitern, TheMue: just return dependency.ErrMissing and it won't try again until its dependencies channge10:27
fwereadedimitern, TheMue: which is quite likely to be "never"10:28
fwereadedimitern, TheMue: so addresser.NewWorker would either return a StringsWorker or a FinishedWorker10:29
TheMuefwereade: a little misusage of ErrMissing, eh?10:29
fwereadeTheMue, sort of, yeah :)10:29
fwereadeTheMue, although it *does* seem appropriate to try again when, eg, the api conn bounces10:30
fwereadeTheMue, you might get a different answer next time ;)10:30
dimiternfwereade, TheMue, ok, in NewWorker we log about it and return FinishedWorker10:30
TheMuefwereade: ah, how I love the benefit of working with interfaces as arguments or return values. does not mean the error, only the return of worker.Worker10:30
fwereadedimitern, sgtm10:30
fwereadeTheMue, yeah, indeed10:30
dimiternfwereade, where does dependency.ErrMissing come into play is what I don't get yet10:31
fwereadedimitern, it's only relevant when I get around to using manifolds10:31
dimiternfwereade, I see, great!10:31
fwereadedimitern, fingers crossed I'll make a start on that this week...10:31
fwereadedimitern, TheMue: thanks guys, gtg10:31
TheMuedimitern: so, master of the saphire cards, how we wonna split it?10:32
dooferladTheMue/dimitern: could I get a quick review? http://reviews.vapour.ws/r/2392/10:33
dooferladdimitern: and when you have a moment, can we discuss my next card.10:33
TheMuedimitern: todays test card can get the addresser startup change card10:33
TheMuedimitern: the firewaller one has should be a new one for backlog10:34
dimiternTheMue, so, it sounds like the following:10:34
dimiterndooferlad, sure, will have a look shortly10:35
dimiternTheMue, a new CanStart() error on the apiserver, returning nil if address allocation with network.AnySubnet returns true, nil10:36
dimiternTheMue, we can have such apiserver methods I think, if not, then (params.BoolResult, error) and the error is not used or result.Error is not - I don't mind10:36
TheMuedimitern: would prefer SupportsAddressAllocation(), CanStart() sounds too generic10:37
dimiternTheMue, ok, but that will cause confusion10:37
dimiternTheMue, let's not call it the same way as the Networking method10:38
dimiternTheMue, CanDeallocateAddresses() is better IMO10:38
TheMuedimitern: thats fine with me, better than asking an API "do you can start?" ;)10:38
TheMuedimitern: and meaning "can I start?"10:39
dimiternTheMue, then, in the NewWorker if it returns != nil, log it and return FinishedWorker, nil10:39
dimiternTheMue, yeah10:39
dimiternTheMue, then the test in the MA will be simply - patch newAddresser to return FinishedWorker, check the next one starts and you're done10:40
TheMuedimitern: btw, I prefer bool instead of misuse nil as "I can"10:40
TheMuedimitern: yep10:41
dimiternTheMue, because testing that CanDeallocateAddresses() works with or without the feature flag is an apiserver test, not an agent or api test10:41
TheMuedimitern: exactly10:41
dimiternTheMue, ok, that's easy - the client-side api returns (bool, error) and you use params.BoolResults (no ",error") at the apiserver side10:42
TheMuedimitern: top10:42
dimiternTheMue, testing the FinishedWorker logic is only relevant to the agent, so test it there only10:43
dimiternTheMue, on the worker side, check it stops and logs when the feature flag is off and that's all I think10:43
TheMuedimitern: sounds pretty complete, yes10:44
dimiternTheMue, awesome! can I ask you to add these steps to the card so it capture what we decided?10:44
dimiternTheMue, I really need to get some branches landed :)10:44
TheMuedimitern: that's what I wonna do and also add a dummy firewaller card to the backlog10:45
dimiternTheMue, cheers!10:45
dimiterndooferlad, back to your review btw10:46
dimiterndooferlad, doesn't the client-side api need to change as well?10:47
dooferladdimitern: probably!10:48
dimiterndooferlad, it does, now it returns response.Results, err10:48
dooferladdimitern: OK, will fix. Sorry, not a great start to the day :-|10:49
dooferladdimitern: did you want me to look at spaces list after this?10:49
dimiterndooferlad, no worries10:50
dimiterndooferlad, yes, I'm almost done with the review10:51
dooferladdimitern: just wanted to know what to queue up next.10:51
dimiterndooferlad, do you mean subnets list?10:51
dooferladdimitern: https://canonical.leankit.com/Boards/View/101652562/11667811510:52
* dimitern looks10:53
dimiterndooferlad, just let me finish the review first, bbiab10:54
dooferladdimitern: sure10:55
* dooferlad seems to have got confused. Perhaps coffee is required.10:58
dimiterndooferlad, reviewed11:17
dimiterndooferlad, let me know what you think11:18
dimiterndooferlad, I forgot to mention the needed client-side api change as well.. adding it now11:18
dimiterndooferlad, hmm, actually returning all results might be better for the CLI - it can display spaces fetched successfully and display errors for others (like juju status does) in the Status field of the output11:22
dimiternperrito666, morning11:23
* perrito666 waits for the coffee before hitting the review queue11:24
dimiterndooferlad, the good thing about this is we don't have to display the error (i.e. change the CLI) right away11:24
ericsnowfwereade, cmars: it would be nice if the new ValueWorker found its way into master sooner rather than later :)14:33
fwereadeericsnow, I'm a little bit distracted right now, but if you'd like to pull it across I will gladly LGTM it, I think the diff should be clean14:35
mupBug #1486074 opened: juju bootstrap fails to work due to incorrect Identities restriction. <juju-core:New> <juju-core 1.24:New for cox-katherine-e> <juju-core 1.26:New> <https://launchpad.net/bugs/1486074>14:35
ericsnowfwereade: k, thanks14:35
fwereadeericsnow, thank you, you're doing the tedious bit ;)14:35
ericsnowfwereade: http://reviews.vapour.ws/r/2397/14:44
ericsnowfwereade, cmars: keep me posted if you do anything to help with nesting dependency engines :)14:44
fwereadeericsnow, ship it :)14:46
ericsnowfwereade: thanks14:46
wwitzel3ericsnow: ping14:51
=== Spads_ is now known as Spads
=== anthonyf is now known as Guest61698
=== Guest61698 is now known as anthonyjf
=== dooferlad_ is now known as dooferlad
dooferladdimitern/TheMue: when you have a moment: http://reviews.vapour.ws/r/2392/15:09
TheMuedooferlad: yep15:09
dimiterndooferlad, will have a look soon15:12
fwereadeaxw, wallyworld: a bit clunky, perhaps, but does http://paste.ubuntu.com/12118757/ strike you as a useful primitive?15:25
dimiterndooferlad, reviewed15:45
mupBug #1486106 opened: TestNetworkInterfaces fails on vivid/wily <ci> <ec2-provider> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1486106>15:47
mupBug #1486106 changed: TestNetworkInterfaces fails on vivid/wily <ci> <ec2-provider> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1486106>15:53
mupBug #1486106 opened: TestNetworkInterfaces fails on vivid/wily <ci> <ec2-provider> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1486106>15:59
mupBug #1461890 changed: leadership unreliable in HA <canonical-bootstack> <ha> <leadership> <juju-core:Fix Released by fwereade> <juju-core 1.24:Fix Released by fwereade> <https://launchpad.net/bugs/1461890>17:53
mupBug #1478024 changed: Looping config-changed hooks in fresh juju-core 1.24.3 Openstack deployment <canonical-bootstack> <leadership> <upgrade-juju> <juju-core:Fix Released by fwereade> <juju-core 1.24:Fix Released by fwereade> <https://launchpad.net/bugs/1478024>17:53
natefinchdamn, just hit one more reason I don't like putting test code in _test packages - if you have tests you need to put in the actual package, you can't access the helper code that is in the _test package.  le sigh.17:56
sinzuikatco: can you ask someone to look into bug 1486166. I cannot tell were the regression lies.17:57
mupBug #1486166: JES deploy fails <ci> <jes> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1486166>17:57
katcosinzui: tal17:58
katcosinzui: dimitern's team is on bug squad this iteration. can it wait until they come back online?17:59
sinzuikatco, sure, I am not going to block trunk for the failure18:03
katcosinzui: ok ty, i'll send an email to dimitern18:03
dimiternkatco, sinzui, I've looked at this one and it seems to me it's badly written - assuming it will only run on environments where the jes feature flag is on18:09
mupBug #1486166 opened: JES deploy fails <ci> <jes> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1486166>18:15
perrito666need to leave for a sec, bbl19:09
alexisbkatco, sinzui I think that is a bug for thumpers team19:12
alexisbI can ping him when he is online19:12
wwitzel3ericsnow: ping, how's it going?20:00
ericsnowwwitzel3: good20:00
* katco grabs popcorn for this fascinating conversation20:07
katcoperrito666: any chance you could do a mini-review for a critical 1.24 bug?20:13
katcoperrito666: http://reviews.vapour.ws/r/2402/20:13
perrito666katco: going20:13
perrito666katco: ship it20:16
katcoperrito666: ty sir20:16
perrito666katco: please update the re-broken bug20:20
katcoperrito666: yep, ty for the reminder20:20
perrito666katco: btw, this might be sympthom of a different problem20:22
katcoperrito666: yes, i agree. but this is a good start as it may be affecting multiple things, and the bug it fixed was much lower priority20:23
perrito666if we pass a set of explicit ident files and expect one of those to be the correct one and it isn t then there is a bigger issue there20:23
katcoperrito666: yep.20:23
katcoperrito666: more trying to address this: https://bugs.launchpad.net/juju-core/+bug/148607420:23
mupBug #1486074: juju bootstrap fails to work due to incorrect Identities restriction. <juju-core:Triaged> <juju-core 1.24:In Progress by cox-katherine-e> <juju-core 1.26:Triaged> <https://launchpad.net/bugs/1486074>20:23
katcoperrito666: err, oops20:24
katcoperrito666: https://bugs.launchpad.net/juju-core/+bug/147263220:24
mupBug #1472632: regression: juju ssh dies with (publickey) <regression> <ssh> <juju-core:Triaged> <juju-core 1.24:Triaged by cox-katherine-e> <https://launchpad.net/bugs/1472632>20:24
perrito666yup, I read the others, the fix does more harm than good :)20:30
katcoperrito666: meaning the fix i backed out? or the fix to fix the fix? :)20:31
* perrito666 is very tempted to answer in french and step this into a whole new realm of lexical complexity20:32
mupBug #1486254 opened: Raw Go errors reported to users <juju-core:New> <https://launchpad.net/bugs/1486254>21:12
mupBug #1486254 changed: Raw Go errors reported to users <juju-core:New> <https://launchpad.net/bugs/1486254>21:18
mupBug #1486254 opened: Raw Go errors reported to users <juju-core:New> <https://launchpad.net/bugs/1486254>21:21
alexisbthumper, ping22:04
thumperalexisb: otp22:05
alexisbthumper, let me know when you are free22:18
perrito666alexisb: oh, just check his refcount22:19
* perrito666 hits himself for that joke22:19
menn0perrito666: no, that was good :)22:21
perrito666menn0: oh, you are too kind.... what do you need?22:25
menn0perrito666: nothing :)22:28
thumperalexisb: free now22:34
thumperalexisb: free now22:38
alexisbthumper, can your team take a look at <https://launchpad.net/bugs/1486166>22:39
mupBug #1486166: JES deploy fails <ci> <jes> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1486166>22:39
thumperyes, I even have that bug open already22:39
thumperalexisb: was it just that?22:39
alexisbunless you have things you want to discuss :)22:39
thumperheh... well nothing I've not said before...22:41
thumpersinzui: the jes deploy test logs are useless due to only having INFO level logging, can you run it with debug please?23:41
thumpermenn0: the jes deploy test is failing as machine 1 and machine 2 cannot download the tools from the state server during cloud-init23:42
thumperinvestigating more23:42

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