[04:06] <huwshimi> thumper: Afternoon. Are you using any features from nose in jujulib?
[04:06] <thumper> no, just running tests
[04:07] <thumper> huwshimi: as long as "make check" works, I'm happy
[04:07] <huwshimi> thumper: 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] <thumper> kk
[04:07] <huwshimi> thumper: Cool, cheers mate.
[06:40] <mup> Bug #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:44] <dimitern> fwereade, ping
[06:44] <fwereade> dimitern, pong
[06:45] <dimitern> fwereade, I'd like to ask you about a quirk with our environ constraints implementation that bit me badly
[06:46] <dimitern> fwereade, 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 replaced
[06:46] <fwereade> dimitern, ok
[06:47] <dimitern> fwereade, 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 it
[06:47] <dimitern> fwereade, the same applies to Networks and Spaces (i'm now adding)
[06:48] <dimitern> fwereade, so my question is - is it a doc issue or by design you can't unset a list-style constraint once set on an environment
[06:49] <fwereade> dimitern, that just sounds like a mistake honestly -- although, I admit, I forget the details
[06:49] <fwereade> dimitern, what happens if you just do set-constraints mem=8G, on anything -- does it not overwrite the whole set of constraints?
[06:49] <fwereade> dimitern, at that level?
[06:50] <dimitern> fwereade, 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:51] <fwereade> dimitern, ahhh -- so it's a mgo level thing? we're not doing $unset when we should?
[06:51] <fwereade> dimitern, would also apply to services, but, yeah, not machines
[06:51] <dimitern> fwereade, 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 result
[06:51] <fwereade> dimitern, ...unless we get cleverer about retry-provissioning-with0different-constraints one day
[06:52] <dimitern> fwereade, it is a mongo thing indeed
[06:53] <fwereade> dimitern, right, yeah, I see -- we just $set and don't $unset everything else
[06:53] <fwereade> dimitern, dammit
[06:53] <dimitern> fwereade, so what I did to fix the failing tests for the time being - added ResetEnvironConstraints which does removeOp+createOp in export_test
[06:53] <dimitern> fwereade, we just $set
[06:54] <dimitern> fwereade, but this needs fixing I think - it's pretty surprising
[06:54] <fwereade> dimitern, I would suggest that those tests are failing because they should, and ResetEnvironConstraints is a Bad Thing
[06:54] <fwereade> dimitern, but, good catch
[06:54] <dimitern> fwereade, 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 them
[06:55] <fwereade> dimitern, I'm not sure how great it is actually
[06:55]  * fwereade thinks
[06:55] <dimitern> fwereade, 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 bug
[06:56] <dimitern> fwereade, tags were totally untested in this set-env-check-inherited-repeat
[06:57]  * fwereade glowers around in an undirected sort of way and reminds everybody that tests are critically important
[06:58] <dimitern> fwereade, I think this deserves a bug report and I'll file one
[06:59] <fwereade> dimitern, at the very least, `an empty value always means "not constrained"` and we're failing there
[06:59] <fwereade> dimitern, https://jujucharms.com/docs/devel/charms-constraints
[06:59] <fwereade> dimitern, yes please
[07:00] <dimitern> fwereade, 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] <fwereade> dimitern, I think we should indeed unset everything not provided
[07:02] <dimitern> fwereade, and provide a "merge existing" command?
[07:10] <dimitern> fwereade, 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 constraints
[07:12] <fwereade> dimitern, yeah, I *think* the merging behaviour can be reasonably considered a bug
[07:12] <fwereade> dimitern, I don't think there's much reason for a merge-existing?
[07:12] <fwereade> dimitern, the inheritance is confusing enough
[07:13] <fwereade> dimitern, effectively having an extra level of it is IMO worse than assuming people know what they want to set
[07:13] <dimitern> fwereade, it's also that it only really matters for lists, as other fields usually have a non-ambiguous "empty" value
[07:14] <dimitern> fwereade, fun fact: "cpu-cores=" != "" != "cpu-cores=0"
[07:14] <fwereade> dimitern, yeah, I think we definitely want to overwrite lists rather than merge
[07:15] <dimitern> fwereade, ok, then I'll make this part of my fix
[07:15] <fwereade> dimitern, yeah, `cpu-cores=` means "fall back" where `cpu-cores=0` means "any number of cores is fine" -- right?
[07:16] <dimitern> fwereade, not quite :) - all of the cases match omitempty
[07:16] <dimitern> fwereade, but only when stored in state
[07:17] <fwereade> dimitern, wait, omitempty ignores the difference between `nil` and `new(int)`?
[07:17] <dimitern> fwereade, but e.g. (*int)(value-with-0) and (*int)(nil) are treated the same
[07:18]  * fwereade resists the urge to render #juju-dev NSFW forever
[07:18] <dimitern> fwereade, :D
[07:18]  * fwereade is going for a quiet rage-filled cigarette
[07:18] <fwereade> dimitern, thanks for many good catches then :)
[07:18] <fwereade> bbs
[07:18] <dimitern> fwereade, cheers :)
[07:30] <dimitern> fwereade, env:"mem=8G", svc:"mem="; effective: "mem=" which is the same as "mem=0"
[07:38] <dimitern> so "X=" is never treated as "", but as "X=<empty-value>" instead
[08:05] <TheMue> morning, lots of traffic on CI *lol*
[08:21] <TheMue> large packages w/o sub-packages lead to story-telling test function names
[09:00] <dimitern> TheMue, dooferlad, guys, will be a couple of minutes late for standup
[09:01] <TheMue> dimitern: ok
[09:03]  * TheMue looks left
[09:03]  * TheMue looks right
[09:04] <TheMue> I'm a poor, lonesome coder *sing*
[09:04] <dooferlad> TheMue: https://plus.google.com/hangouts/_/canonical.com/juju-sapphire?authuser=0 ?
[09:05] <TheMue> dooferlad: 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] <dooferlad> TheMue: we are in there too
[09:05] <TheMue> dooferlad: will reconnect
[09:31] <fwereade> TheMue, dimitern: why are we pulling environ config down to the machine agent to figure out if we support networking?
[09:32] <fwereade> TheMue, dimitern: shouldn't this be a job?
[09:32] <dimitern> fwereade, because we need an environs.Environ to type-assert on
[09:33] <fwereade> dimitern, I don't think there's any justification for creating an environ in an agent
[09:34] <fwereade> dimitern, we can figure that out at machine-creation time, can't we? when we've already got the state policy available?
[09:36] <dimitern> fwereade, it a different sort of job - address (de)allocation and manage networking
[09:39] <fwereade> dimitern, yeah, I'm not saying its the same as JMN -- but wouldn't it be JobAllocateAddresses or something?
[09:41] <dimitern> fwereade, yeah, I agree the best thing is to add a job
[09:42] <dimitern> fwereade, 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] <dimitern> fwereade, and then build on top of this by introducing a job
[09:42] <dimitern> fwereade, sane?
[09:43] <fwereade> dimitern, 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 problems
[09:44] <fwereade> dimitern, imo the machine agent shouldn't even know what sort of provider it's running on
[09:47] <dimitern> fwereade, fwiw this only happens once per environment
[09:48] <fwereade> dimitern, how does that make env-construction in the machine agent any less evil?
[09:48] <dimitern> fwereade, and we did drop one (the only remaining?) provider type checks in the MA using JobManageNetworking
[09:48] <TheMue> fwereade: how do you compare address allocation support with firewaller modes? the depend on the providers capabilities too. could a similar approach be feasable?
[09:49] <dimitern> fwereade, why is it evil for the JobManageEnviron agent?
[09:49] <dimitern> fwereade, it has full access to it anyway
[09:50] <fwereade> dimitern, the *agent* shouldn't know anything about the environ
[09:50] <fwereade> dimitern, it might run some job that knows about it
[09:50] <fwereade> dimitern, but that's a completely distinct responsibility
[09:51] <fwereade> TheMue, I'd say that firewaller modes should not be using environ config either
[09:52] <dimitern> fwereade, by "some job that knows about it" you mean a worker that pulls the environ config on start?
[09:52] <fwereade> dimitern, yeah
[09:52] <dimitern> fwereade, even if it doesn't need it except to check whether it needs to do anything at all
[09:52] <fwereade> dimitern, via a facade, and for a worker, that's allowed to know about it
[09:53] <fwereade> dimitern, do we know why we added Environment() to the Agent facade in the first place?
[09:53] <dimitern> fwereade, not really
[09:53] <dimitern> fwereade, I assume because it was there
[09:54] <fwereade> dimitern, oh, feck, it's not even that
[09:54] <dimitern> TheMue, +1 about the firewaller
[09:54] <fwereade> dimitern, someone just thought "lol  I'll use the wrong facade in the agent"
[09:54] <dimitern> fwereade, :)
[09:55] <dimitern> fwereade, ok, can we agree to add a job later?
[09:55] <dimitern> fwereade, I promise we won't forget about it
[09:55] <TheMue> dimitern: 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] <fwereade> dimitern, TheMue: this all seems like code that's been added in the last couple of days though
[09:56] <fwereade> dimitern, TheMue: and should frankly have never passed review
[09:56] <dimitern> fwereade, the change is strictly an improvement over what we had before
[09:56] <TheMue> "should" is a wonderful subjunctive
[09:57] <fwereade> dimitern, TheMue: at the *very least*, why is this stuff not handled inside the addresser worker?
[09:57] <dimitern> fwereade, this check is simply for a better UX - not to spam the logs with "addresses: not starting.."
[09:57] <TheMue> fwereade: yep, agree to dimitern, the old approach always started the worker, got the events but done nothing
[09:57] <dimitern> fwereade, it used to be, but TheMue suggested it should be done at the apiserver level with a single call
[09:58] <dimitern> fwereade, and I liked the idea of not violating layers unnecessarily
[09:58] <fwereade> dimitern, 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 env
[09:58] <dimitern> fwereade, 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:59] <TheMue> dimitern: the dont-start-not-needed-worker came later and is a different one. imho that's wht we currently talk about
[09:59] <dimitern> fwereade, it exits quietly ever 3s as it gets restarted by the runner
[09:59] <fwereade> dimitern, TheMue: wait, I hope it doesn't use state directly, does it?
[10:00] <TheMue> fwereade: nope, that has been the original idea of the change
[10:00] <dimitern> fwereade, not anymore, that was the whole point of the exercise - it uses its own apiserver facade
[10:00] <TheMue> fwereade: no more state usage
[10:00] <fwereade> ah cool :)
[10:00] <TheMue> :)
[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:01] <dimitern> fwereade, because its on the JobManageEnviron MA
[10:01] <fwereade> dimitern, that dooesn't mean iit gets to see mongo
[10:01] <dimitern> fwereade, this card along with a bunch of others (some of which already landed) is our effort to cut state access for JME workers
[10:02] <fwereade> dimitern, re the 3s restart -- why don't you just *return nil*?
[10:02] <fwereade> dimitern, meaning "I have done all the work I can, don't bother me agaib"
[10:02] <dimitern> fwereade, if the runner supported a way to tell it "don't restart me anymore"
[10:02] <dimitern> fwereade, it would've been simpler
[10:03] <dimitern> fwereade, IIRC that leads to the same thing
[10:03] <fwereade> runner.go:205
[10:04] <fwereade> runner_test.go:55
[10:05] <dimitern> fwereade, hmm, ok fair enough
[10:05] <TheMue> fwereade: nice
[10:05] <dimitern> fwereade, so it does not restart if it return nil from the loop?
[10:05] <fwereade> dimitern, yeah
[10:05] <dimitern> fwereade, that's ok, but not good enough I'm afraid
[10:05] <fwereade> dimitern, go on
[10:05] <dimitern> fwereade, we need a way not to start it in the first place
[10:05] <fwereade> dimitern, why?
[10:06] <TheMue> fwereade: dimitern: so addresses starts, first time talks to API, get's a not supported error back, and quits nicely
[10:06] <dimitern> fwereade, i.e. a way to return something != nil from New() that tells the runner not to run it
[10:06] <TheMue> addresser
[10:06] <fwereade> dimitern, TheMue: why can't the worker just detect that it can't do anything and stopp itself?
[10:07] <fwereade> dimitern, TheMue: it's not an error -- it has examined the world and determined that it doesn't need to do anything ever
[10:07] <dimitern> fwereade, 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:08] <TheMue> fwereade: 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] <fwereade> dimitern, TheMue: I'd prefer a sepaarate api call, rather than overloading that one
[10:09] <dimitern> fwereade, that's fine - it can be separate
[10:09] <TheMue> sounds good
[10:09] <dimitern> fwereade, what's important is will it work before the loop starts
[10:09] <fwereade> TheMue, 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 worker
[10:09] <fwereade> TheMue, dimitern: although actually, yeah, maybe it *is* just part of JME
[10:12] <fwereade> TheMue, dimitern: this may be relevant: in the unit agent, now, the manifolds themselves return dependency.ErrMissing when started in an inappropriate context
[10:13] <fwereade> TheMue, dimitern: this means we can have nice declarative conditional-free definitions of various sets of workers and their dependencies
[10:13] <fwereade> TheMue, dimitern: relevant/sane?
[10:14] <TheMue> fwereade: have to read tha last sentence twice
[10:14] <fwereade> TheMue, dimitern: see cmd/jujud/agent/unit/manifolds.go
[10:14] <TheMue> fwereade: thx for the hint
[10:15] <fwereade> TheMue, dimitern: and then the feature-flag checkinng inside worker/rsyslog and worker/logsender
[10:15] <fwereade> TheMue, dimitern: in practice we'll only run one of those at a time I think
[10:16] <dimitern> fwereade, I like this a lot
[10:16] <fwereade> TheMue, dimitern: but they can make that determination individually
[10:16] <dimitern> fwereade, it will also make testing this a *lot* easier
[10:16] <fwereade> dimitern, :D
[10:16] <dimitern> fwereade, one of each *per environ*
[10:16] <fwereade> dimitern, yeah, agreed
[10:17] <fwereade> dimitern, TheMue: so, to reiterate
[10:18]  * TheMue listens
[10:18] <dimitern> fwereade, yeah, let's summarize
[10:18] <fwereade> dimitern, TheMue: I don't think we do need a separate job there, sorry for the noise on that front
[10:18] <dimitern> fwereade, in practice, no we don't
[10:19] <fwereade> dimitern, TheMue: but if we can just make the addresser (and firewaller?) check for their own validity, log once, and return no error
[10:19] <fwereade> dimitern, TheMue: then we get a slightly cleaner agent
[10:19] <fwereade> dimitern, TheMue: for relatively little in the way of code changes
[10:19] <TheMue> fwereade: dimitern: oh yes +100
[10:20] <fwereade> dimitern, TheMue: and it *also* makes my job much easier when I come to use manifolds in the machine agent
[10:20] <fwereade> dimitern, TheMue: which I am very keen to do :)
[10:20] <TheMue> fwereade: so I'm changing addresser again and you the firewaller *lol*
[10:21] <fwereade> TheMue, if you can bear to hit both of them I would be most grateful :)
[10:21] <dimitern> TheMue, fwereade, let's not do all at once though - first the addresses, then the firewaller
[10:21] <fwereade> dimitern, yeah, that works for me
[10:21] <TheMue> +1
[10:21] <dimitern> addresser even
[10:21] <fwereade> dimitern, TheMue: hopefully having done one will make the second one trivial anyeay
[10:22] <dimitern> fwereade, it should, yeah
[10:22] <fwereade> dimitern, TheMue: cool, thank you very much
[10:23] <fwereade> dimitern, TheMue: and then RB2390 becomes ~redundant, in favour of another unit test or two in each of the relevant workers
[10:23] <dimitern> fwereade, so, if I'm getting it right, you suggest to have a method in the workers' apiserver facade like CanRun()
[10:23] <TheMue> fwereade: 2390 will be dropped
[10:23] <dimitern> fwereade, which is called at the start of Handle() ? Or in the constructor returning the worker?
[10:24] <dimitern> fwereade, I'd really like it if we can avoid starting the loop if we can - i.e. constructor is better
[10:24] <fwereade> dimitern, 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] <fwereade> dimitern, little bit hackish
[10:25] <dimitern> fwereade, this assumes we have a special error like ErrCannotStart, which startWorker understands
[10:25] <fwereade> dimitern, but easily replaceable, I think, when I use manifolds
[10:25] <fwereade> dimitern, yeah, if you want to add ErrWorkerNotNeeded handling to worker.Runner, that could work
[10:25] <fwereade> dimitern, but Runner *is* a bit hairy
[10:26] <dimitern> fwereade, yeah, very much so - ok, then constructing a "degenerate" worker in this case might be better until it can be converted to use manifolds
[10:27] <fwereade> dimitern, TheMue: http://paste.ubuntu.com/12117329/
[10:27] <fwereade> dimitern, TheMue: and then for the manifolds we don't even need that
[10:27] <TheMue> dimitern: so this degenerated one has a Handle(), but that only returns I'mNotNeeded
[10:27] <fwereade> dimitern, TheMue: just return dependency.ErrMissing and it won't try again until its dependencies channge
[10:28] <fwereade> dimitern, TheMue: which is quite likely to be "never"
[10:29] <fwereade> dimitern, TheMue: so addresser.NewWorker would either return a StringsWorker or a FinishedWorker
[10:29] <TheMue> fwereade: a little misusage of ErrMissing, eh?
[10:29] <fwereade> TheMue, sort of, yeah :)
[10:30] <fwereade> TheMue, although it *does* seem appropriate to try again when, eg, the api conn bounces
[10:30] <fwereade> TheMue, you might get a different answer next time ;)
[10:30] <dimitern> fwereade, TheMue, ok, in NewWorker we log about it and return FinishedWorker
[10:30] <TheMue> fwereade: 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.Worker
[10:30] <fwereade> dimitern, sgtm
[10:30] <fwereade> TheMue, yeah, indeed
[10:31] <dimitern> fwereade, where does dependency.ErrMissing come into play is what I don't get yet
[10:31] <fwereade> dimitern, it's only relevant when I get around to using manifolds
[10:31] <dimitern> fwereade, I see, great!
[10:31] <fwereade> dimitern, fingers crossed I'll make a start on that this week...
[10:31] <fwereade> dimitern, TheMue: thanks guys, gtg
[10:32] <TheMue> dimitern: so, master of the saphire cards, how we wonna split it?
[10:33] <dooferlad> TheMue/dimitern: could I get a quick review? http://reviews.vapour.ws/r/2392/
[10:33] <dooferlad> dimitern: and when you have a moment, can we discuss my next card.
[10:33] <TheMue> dimitern: todays test card can get the addresser startup change card
[10:34] <TheMue> dimitern: the firewaller one has should be a new one for backlog
[10:34] <dimitern> TheMue, so, it sounds like the following:
[10:35] <dimitern> dooferlad, sure, will have a look shortly
[10:36] <dimitern> TheMue, a new CanStart() error on the apiserver, returning nil if address allocation with network.AnySubnet returns true, nil
[10:36] <dimitern> TheMue, 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 mind
[10:37] <TheMue> dimitern: would prefer SupportsAddressAllocation(), CanStart() sounds too generic
[10:37] <dimitern> TheMue, ok, but that will cause confusion
[10:38] <dimitern> TheMue, let's not call it the same way as the Networking method
[10:38] <dimitern> TheMue, CanDeallocateAddresses() is better IMO
[10:38] <TheMue> dimitern: thats fine with me, better than asking an API "do you can start?" ;)
[10:39] <TheMue> dimitern: and meaning "can I start?"
[10:39] <dimitern> TheMue, then, in the NewWorker if it returns != nil, log it and return FinishedWorker, nil
[10:39] <dimitern> TheMue, yeah
[10:40] <dimitern> TheMue, then the test in the MA will be simply - patch newAddresser to return FinishedWorker, check the next one starts and you're done
[10:40] <TheMue> dimitern: btw, I prefer bool instead of misuse nil as "I can"
[10:41] <TheMue> dimitern: yep
[10:41] <dimitern> TheMue, because testing that CanDeallocateAddresses() works with or without the feature flag is an apiserver test, not an agent or api test
[10:41] <TheMue> dimitern: exactly
[10:42] <dimitern> TheMue, ok, that's easy - the client-side api returns (bool, error) and you use params.BoolResults (no ",error") at the apiserver side
[10:42] <TheMue> dimitern: top
[10:43] <dimitern> TheMue, testing the FinishedWorker logic is only relevant to the agent, so test it there only
[10:43] <dimitern> TheMue, on the worker side, check it stops and logs when the feature flag is off and that's all I think
[10:44] <TheMue> dimitern: sounds pretty complete, yes
[10:44] <dimitern> TheMue, awesome! can I ask you to add these steps to the card so it capture what we decided?
[10:44] <dimitern> TheMue, I really need to get some branches landed :)
[10:45] <TheMue> dimitern: that's what I wonna do and also add a dummy firewaller card to the backlog
[10:45] <dimitern> TheMue, cheers!
[10:46] <dimitern> dooferlad, back to your review btw
[10:47] <dimitern> dooferlad, doesn't the client-side api need to change as well?
[10:48] <dooferlad> dimitern: probably!
[10:48] <dimitern> dooferlad, it does, now it returns response.Results, err
[10:49] <dooferlad> dimitern: OK, will fix. Sorry, not a great start to the day :-|
[10:49] <dooferlad> dimitern: did you want me to look at spaces list after this?
[10:50] <dimitern> dooferlad, no worries
[10:51] <dimitern> dooferlad, yes, I'm almost done with the review
[10:51] <dooferlad> dimitern: just wanted to know what to queue up next.
[10:51] <dimitern> dooferlad, do you mean subnets list?
[10:52] <dooferlad> dimitern: https://canonical.leankit.com/Boards/View/101652562/116678115
[10:53]  * dimitern looks
[10:54] <dimitern> dooferlad, just let me finish the review first, bbiab
[10:55] <dooferlad> dimitern: sure
[10:58]  * dooferlad seems to have got confused. Perhaps coffee is required.
[11:17] <dimitern> dooferlad, reviewed
[11:18] <dimitern> dooferlad, let me know what you think
[11:18] <dimitern> dooferlad, I forgot to mention the needed client-side api change as well.. adding it now
[11:22] <dimitern> dooferlad, 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 output
[11:22] <perrito666> morning
[11:23] <dimitern> perrito666, morning
[11:24]  * perrito666 waits for the coffee before hitting the review queue
[11:24] <dimitern> dooferlad, the good thing about this is we don't have to display the error (i.e. change the CLI) right away
[14:33] <ericsnow> fwereade, cmars: it would be nice if the new ValueWorker found its way into master sooner rather than later :)
[14:34] <ericsnow> (https://github.com/juju/juju/pull/3006)
[14:35] <fwereade> ericsnow, 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 clean
[14:35] <mup> Bug #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] <ericsnow> fwereade: k, thanks
[14:35] <fwereade> ericsnow, thank you, you're doing the tedious bit ;)
[14:44] <ericsnow> fwereade: http://reviews.vapour.ws/r/2397/
[14:44] <ericsnow> fwereade, cmars: keep me posted if you do anything to help with nesting dependency engines :)
[14:46] <fwereade> ericsnow, ship it :)
[14:46] <ericsnow> fwereade: thanks
[14:51] <wwitzel3> ericsnow: ping
[15:09] <dooferlad> dimitern/TheMue: when you have a moment: http://reviews.vapour.ws/r/2392/
[15:09] <TheMue> dooferlad: yep
[15:12] <dimitern> dooferlad, will have a look soon
[15:25] <fwereade> axw, wallyworld: a bit clunky, perhaps, but does http://paste.ubuntu.com/12118757/ strike you as a useful primitive?
[15:33] <benji> k
[15:34] <benji> #wrongwindow
[15:45] <dimitern> dooferlad, reviewed
[15:47] <mup> Bug #1486106 opened: TestNetworkInterfaces fails on vivid/wily <ci> <ec2-provider> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1486106>
[15:53] <mup> Bug #1486106 changed: TestNetworkInterfaces fails on vivid/wily <ci> <ec2-provider> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1486106>
[15:59] <mup> Bug #1486106 opened: TestNetworkInterfaces fails on vivid/wily <ci> <ec2-provider> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1486106>
[17:53] <mup> Bug #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] <mup> Bug #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:56] <natefinch> damn, 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:57] <sinzui> katco: can you ask someone to look into bug 1486166. I cannot tell were the regression lies.
[17:57] <mup> Bug #1486166: JES deploy fails <ci> <jes> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1486166>
[17:58] <katco> sinzui: tal
[17:59] <katco> sinzui: dimitern's team is on bug squad this iteration. can it wait until they come back online?
[18:03] <sinzui> katco, sure, I am not going to block trunk for the failure
[18:03] <katco> sinzui: ok ty, i'll send an email to dimitern
[18:09] <dimitern> katco, 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 on
[18:15] <mup> Bug #1486166 opened: JES deploy fails <ci> <jes> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1486166>
[19:09] <perrito666> need to leave for a sec, bbl
[19:12] <alexisb> katco, sinzui I think that is a bug for thumpers team
[19:12] <alexisb> I can ping him when he is online
[20:00] <wwitzel3> ericsnow: ping, how's it going?
[20:00] <ericsnow> wwitzel3: good
[20:07]  * katco grabs popcorn for this fascinating conversation
[20:13] <katco> perrito666: any chance you could do a mini-review for a critical 1.24 bug?
[20:13] <katco> perrito666: http://reviews.vapour.ws/r/2402/
[20:13] <perrito666> katco: going
[20:16] <perrito666> katco: ship it
[20:16] <katco> perrito666: ty sir
[20:20] <perrito666> katco: please update the re-broken bug
[20:20] <katco> perrito666: yep, ty for the reminder
[20:22] <perrito666> katco: btw, this might be sympthom of a different problem
[20:23] <katco> perrito666: yes, i agree. but this is a good start as it may be affecting multiple things, and the bug it fixed was much lower priority
[20:23] <perrito666> if 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 there
[20:23] <katco> perrito666: yep.
[20:23] <katco> perrito666: more trying to address this: https://bugs.launchpad.net/juju-core/+bug/1486074
[20:23] <mup> Bug #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:24] <katco> perrito666: err, oops
[20:24] <katco> perrito666: https://bugs.launchpad.net/juju-core/+bug/1472632
[20:24] <mup> Bug #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:30] <perrito666> yup, I read the others, the fix does more harm than good :)
[20:31] <katco> perrito666: meaning the fix i backed out? or the fix to fix the fix? :)
[20:32]  * perrito666 is very tempted to answer in french and step this into a whole new realm of lexical complexity
[20:32] <katco> haha
[21:12] <mup> Bug #1486254 opened: Raw Go errors reported to users <juju-core:New> <https://launchpad.net/bugs/1486254>
[21:18] <mup> Bug #1486254 changed: Raw Go errors reported to users <juju-core:New> <https://launchpad.net/bugs/1486254>
[21:21] <mup> Bug #1486254 opened: Raw Go errors reported to users <juju-core:New> <https://launchpad.net/bugs/1486254>
[22:04] <alexisb> thumper, ping
[22:05] <thumper> alexisb: otp
[22:18] <alexisb> thumper, let me know when you are free
[22:19] <perrito666> alexisb: oh, just check his refcount
[22:19]  * perrito666 hits himself for that joke
[22:19] <alexisb> :)
[22:21] <menn0> perrito666: no, that was good :)
[22:25] <perrito666> menn0: oh, you are too kind.... what do you need?
[22:28] <menn0> perrito666: nothing :)
[22:34] <thumper> alexisb: free now
[22:38] <thumper> alexisb: free now
[22:39] <alexisb> thumper, can your team take a look at <https://launchpad.net/bugs/1486166>
[22:39] <mup> Bug #1486166: JES deploy fails <ci> <jes> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1486166>
[22:39] <thumper> yes, I even have that bug open already
[22:39] <thumper> alexisb: was it just that?
[22:39] <alexisb> yep
[22:39] <alexisb> unless you have things you want to discuss :)
[22:41] <thumper> heh... well nothing I've not said before...
[23:41] <thumper> sinzui: the jes deploy test logs are useless due to only having INFO level logging, can you run it with debug please?
[23:42] <thumper> menn0: the jes deploy test is failing as machine 1 and machine 2 cannot download the tools from the state server during cloud-init
[23:42] <thumper> investigating more