[00:01] cherylj: I've gotta run; others should be able to help keep your merge train moving though :) [00:02] thanks, ericsnow! === kadams54 is now known as kadams54-away [01:04] cherylj: is the description at the top of LICENCE a requirement? (I'm going to be adding a new repo later on, so I will add LICENCE to it) [01:04] cherylj: I'm referring to, e.g. "This package deals with Juju names." [01:05] axw: The answer I got when I asked was that it's a courtesy / convention and not a hard requirement [01:05] cherylj: thanks [01:05] np! :) [01:27] wallyworld: reviewed status-get [01:27] axw: tyvm [01:48] wallyworld: can you please add "hackers" to the replicaset repo? [01:48] sure [01:49] done [01:49] ta [01:50] cherylj: if you're still awake/working, would you mind casting your eyes over https://github.com/juju/replicaset briefly to check that I did it right? [01:58] axw: licence file not quite right - see the recent commits to 1.22 or master i think [01:59] you don't need the whole file - just a copyright statement and a reference to the licence [01:59] wallyworld: which repo? I copied this from juju/txn [01:59] axw: https://github.com/juju/juju/blob/1.22/LICENCE [01:59] axw: also, status-get updated, ptal when free [02:00] wallyworld: possibly different for that, because we don't have an exception to AGPL [02:00] wallyworld: we do for LGPL though [02:01] looking [02:03] axw: i oasted a link above to the licence file recently added to 1.22 for juju [02:05] wallyworld: yes... that is AGPL [02:05] wallyworld: the replicaset one will be LGPL+exception [02:07] wallyworld: just responded, sorry I realised I should hit shipit... I'll just take another look over [02:09] wallyworld: done [02:10] thumper: is the charm repo really meant to be AGPL? [02:10] axw: I'm not sure, but since it wasn't a change, I let it through [02:11] personally I would have thought lgpl [02:11] ah ok [02:11] thumper: do you know what the deal is with including the full copyright text? [02:11] I copied from juju/txn, which has the full text for LGPL. the AGPL ones are abridged [02:14] axw: no, was looking at the bug [03:04] anastasiamac_: FYI, I found the following failure on vivid: #1436397 [03:04] Bug #1436397: map-order sensitive test in md/juju/storage needs to be fixed

[03:04] ericsnow: i saw :( [03:04] ericsnow: will aim to fix today... later on... sometime :D [03:04] anastasiamac_: should be pretty easy to fix [03:04] anastasiamac_: sound good :) [03:04] ericsnow: yep :D [03:06] ericsnow: m surprised to c u here now... it's 1pm here in Brisbane... it must be somewhere in the middle of the night where u r :D [03:06] anastasiamac_: nah, it's about 9pm (happened to be following up on a few little things) [03:07] ericsnow: 9pm is an ok office hour? :D [03:07] anastasiamac_: well, for our team I tend to have to follow-up on stuff in the evening (but try to limit myself) [03:09] ericsnow: :) [03:09] ericsnow: map ordering is my 2nd best nemesis :D [03:11] can anyone remind me of the process of connecting to mongod when running local provider? [03:11] via the mongo client [03:18] axw: thanks for the review [03:18] axw: would you mind throwing a ship-it onto that review request; I'll get a patch up and merge it later (probably tomorrow) [03:18] ericsnow: yes, will do, thanks [03:19] axw: much appreciated [03:21] ericsnow: no worries. I'm thinking about using the GCE provider to run a buildbot slave, hence why I was testing. I think this will lower the barrier to entry nicely [03:22] axw: sweet [03:22] axw: keep the feedback coming :) [03:26] axw: here's the status-set if you have a chance at some point http://reviews.vapour.ws/r/1279/ [03:26] wallyworld: yup, just opened it [03:27] wallyworld: could you (or your delegate) follow up on #1434437 [03:27] Bug #1434437: juju restore failed with "error: cannot update machines: machine update failed: ssh command failed: "

[03:27] wallyworld: the reporter is about your TZ [03:38] wallyworld: couple of questions on the review === kadams54 is now known as kadams54-away [03:53] axw: thanks for review, issues fixed [03:53] ta, looking [03:54] wallyworld: btw, what will go in the "data"? [03:54] modification time? [03:54] * axw checks spec [03:57] wallyworld: LGTM, added a comment as food for thought [03:58] -_- [03:58] * axw wishes wallyworld would get a refresh already [03:59] wallyworld: LGTM, added a comment as food for thought [03:59] sure, np [03:59] ty [04:01] axw: updated time will be shown, but it's not implemented yet [04:01] what we currently have is what's displayed [04:02] wallyworld: from my glance over the spec I didn't see anything other than status, message and update time in the output [04:02] wallyworld: so my question is, should we really be splatting out a k/v map, or should we just extract the update time [04:05] Bug #1436655 was opened: gce provider should stop using deprecated zone europe-west1-a

[04:09] cherylj (for you to look at in the morning) this is the fix for the issue we talked about this morning: http://reviews.vapour.ws/r/1280/ [04:10] also, any reviewer... http://reviews.vapour.ws/r/1280/ [04:52] wallyworld: should "juju cached-images" work with the local provider? [04:52] wallyworld: cos it doesn't [04:53] axw: yes [04:53] it did when i last tested it [04:53] as that's how it was developed [04:53] what's it doing (or not)? [04:53] wallyworld: I see. [04:53] juju cached-images list [04:53] no matching images found [04:53] wallyworld: ^ [04:53] hmmm [04:54] doesn't matter if I specify a filter or not [04:54] i reckon JES has stuffed it up [04:54] there's an environ filter or something [04:54] just a guess [04:54] mk [04:55] wallyworld: also, I set "allow-lxc-loop-mounts:true" in environments.yaml but "loop" still doesn't work on local :( [04:55] oh, what does the lxc.conf have in it? [04:56] i didn't test end-end cause at the time, it wasn't working, i just ensured the lxc.conf was correct [04:56] wallyworld: where's that again? [04:57] lxc-broker.go maybe, i'll check [04:57] I mean, where's lxc.conf [04:58] wallyworld: hum, my container doesn't have an lxc.conf... [04:58] hmmm, /var/lib/lxc/containers/... i would have thought [04:59] there's 2 files we generate i think [04:59] ok, I'll go digging [04:59] config and something else i can't recall [05:04] axw: i think it's /var/lib/lxc//config [05:05] wallyworld, axw, if you're not using lxc clone, the generated lxc.conf should be in /var/lib/juju/containers//, otherwise only the template lxc container has lxc.conf, the rest use the run-time config in /var/lib/lxc//config [05:05] I see [05:05] dimitern: so i was half right :-) [05:06] :) [05:06] or fully right for me as i don't use templates [05:06] wallyworld: welp, the aa bits aren't making it into the config file... will keep digging [05:06] ok, sorry it's not working [05:07] axw, I guess you are using lxc-clone: true then? [05:07] dimitern: no [05:07] dimitern: it's not in the template either, in any case [05:08] axw, ah, ok [05:12] wallyworld: ah, I know what happened. loop is "dynamic", so there are no volumes passed to StartInstance [05:12] wallyworld: I think we just need to enable it if the config attr is set [05:12] ah yes [07:48] hi [07:48] I have a few questions about windows support in juju-core, especially the uniter [07:49] in https://github.com/juju/juju/blob/master/worker/uniter/paths_test.go#L83 [07:49] will those tests work in windows? [07:49] are they supposed to? [09:09] hello guys [09:09] is there a way to get from CLI the ip address of a service? [09:09] I mean, I can do it with stat - but need to do greps and cuts to get just the IP [09:09] (I need it in a script) [09:23] Muntaner, try something like: addr=`juju run --unit myunit/1 unit-get private-address` [09:25] dimitern, this just executes the unit-get command? [09:25] dimitern, just seen the man - yes, thanks :) [09:26] Muntaner, yeah [09:26] np :) [09:32] dimitern, which name should I specify for the 0 machine? [09:32] Muntaner, use --machine 0 [09:34] Muntaner, but didn't you want the address of the unit? [09:35] dimitern, no, I need the floating IP of the "bootstraper" machine [09:35] dimitern, I strangely get a "unrecognized argoment: public-address" with the unit-get [09:35] unrecognized args* [09:36] maybe should I specify the location of the unit-get command? [09:37] Muntaner, ah, ok - you can't get the floating IP like this (from the machine itself) [09:37] Muntaner, because it's something the cloud provider knows, not the machine itself [09:38] dimitern, aw. Isn't there any other option? [09:42] Muntaner, 3 options - 1) parsing the output of juju status like you do, 2) (if you just need the apiserver public address) juju api-endpoints outputs IP:port (e.g. 10.0.0.1:17070), which is easier to parse; 3) use the cloud command line client [09:54] Bug #1436766 was opened: juju run fails on manually provisioned instance [09:54] dimitern: i just noticed this: github.com/juju/juju/service includes github.com/juju/testing as a dependency, which is a big no-no [09:55] dimitern: i thought there were tests in place to make sure that the main juju binaries don't include tests (e.g. gopkg.in/check.v1) as a dependency [09:56] ericsnow, jam: ^ [09:58] rogpeppe, where's that? [09:58] dimitern: where's what? [09:59] rogpeppe, the import - which branch, file? [09:59] dimitern: package github.com/juju/juju/service, file fake.go [09:59] rogpeppe, hmm that's a good catch! [10:00] rogpeppe, it should've been in a service/testing subpackage [10:00] dimitern: yes [10:00] rogpeppe, dimitern I can do that now if you're busy [10:00] dimitern: and i think there should be some test that would catch that - it's not an uncommon mistake [10:00] rogpeppe, dimitern I'm still trying to to work out how I'm going to arrange my day [10:01] rogpeppe, dimitern this would be a nice distraction [10:01] rogpeppe, mattyw, sorry my standup is just starting [10:01] dimitern: np [10:01] dimitern: perhaps you could mention it [10:01] rogpeppe, will do [10:01] actually it's the weekly team meeting now [10:08] dimitern: there's also github.com/juju/juju/service/systemd [10:08] dimitern: testing.go in there [10:19] voidspace, dooferlad, TheMue, I've joined our standup [10:19] wallyworld, I like the pep talks - thanks. enjoy your wine [10:19] dimitern: we've all stayed in the last one [10:19] dimitern: we're joining you though... [10:19] mattyw: hey matty, no worries, sorry i didn't mention metric first up [10:20] wallyworld, no problem :) I can't remember what everyone else has worked on - so I'm surprised you did as well as you did :) [10:20] mattyw: yeah, i'm sure i left off at least one or two other items :-) [10:53] fwereade: hey, you around? [11:00] wallyworld, heyhey [11:01] fwereade: i ended up landing the status-get and set stuff after review by andrew, but am more than happy to rework anything if needed [11:01] i also have the new branch mostly complete, except for more tests etc [11:02] would be great if you could take a look [11:02] https://github.com/juju/juju/compare/juju:master...wallyworld:unit-agent-state?expand=1 [11:02] i had to expand an interface or two [11:02] to allow the setting of an attribute in uniter state from a hook context [11:02] worker uniter tests all pass [11:03] got to add a few more potentially, and also look to see if cmd/juju/status tests pass (which they won't) [11:05] wallyworld, yeah, I must say that OperationStateAccessor raises an eyebrow or two [11:06] fwereade: so, in a jujuc context where set status is called via the hook tool, i need to set a bool in uniter state [11:07] to record that the set status call happened [11:07] wallyworld, right, but operation state used to be exclusively set by the executor, taking advice from the operations that actually executed [11:07] wallyworld, now... anything that can see an operation can do wtf it likes to state [11:07] fwereade: operations controller by the uniter [11:08] fwereade: so i could restrict the method to only allow that specific bool to be set [11:08] unless you have another suggestion? [11:09] bear in mind this is more or less my first foray into the uniter code, so may be missing a few key tings [11:11] sure, I'm thinking about it [11:12] i can hear the cogs turning :-) [11:12] wallyworld, sorry, I'm being dense, I can't follow the chain that causes a different state to be written or not [11:30] wallyworld, dammit, what was the last think you saw me say? === beisner- is now known as beisner [11:30] wallyworld, but passing operationExecutor into the runner factory feels wrong [11:30] fwereade: what was the last thing you saw me say? [11:31] ericsnow, natefinch, please have a look at this when you can http://reviews.vapour.ws/r/1282/ - fixes bug 1436191 [11:31] [21:15:02] but till now, uniter state has been controlled by the executor which is running the hooks [11:31] [21:15:26] yes, it did feel wrong, hence i tried to use an interface that restricted the exposure [11:31] [21:15:37] i didn't immediately see another way to do it [11:31] [21:16:19] fwereade: so [11:31] [21:16:35] OperationsStateAccessor *ony* exposes the CharmSetStatus() method [11:31] [21:16:38] only [11:31] Bug #1436191: gce: bootstrap instance has no network rule for API

[11:31] [21:17:08] hence even though we pass in the executor, the code running in the jujuc context can only do that one thing [11:31] [21:17:29] i kept telling myself that was "acceptable" [11:31] [21:17:59] --> rvba` (~rvba@culvain.gromper.net) has joined #juju-dev [11:31] [21:18:10] that CharmSetStatus() method only sets that one bool in uniter state [11:31] [21:18:30] so the code in a jujuc context can't do any harm as such [11:32] wallyworld, essay in http://paste.ubuntu.com/10683319/ [11:32] looking [11:32] wallyworld, but I think I was only just figuring out the real issue [11:32] wallyworld, namely that status-set-related state changes should only happen in hooks [11:33] wallyworld, and hence should be exclusively the responsibility of the runHook op -- by putting it on the context *anything* that sets status will trigger it [11:33] fwereade_: a hook tool can be called outside a a hook [11:33] wallyworld, actions, juju-run, whatever [11:33] ah right juju-run, yes [11:33] wallyworld, (and, hmm, debug-hooks -- how does that affect the story?) [11:34] wallyworld, but anyway I *think* that runHook.Execute is the only thing that needs to know whether status-set was called [11:35] wallyworld, and that's always got access to a context [11:35] fwereade_: i was thinking, perhaps wrongly, that we'd only want to set the workload status in commit() [11:35] cause i was thinking it was like a db op - there could be a rollback [11:36] so we run execute, and if all went well, we commit [11:36] and that's when we need to set the workload status to unknown if status-set was not called [11:36] or to terminated if stop was called [11:37] fwereade_: and i also thought hook tools were serialised with hooks [11:37] wallyworld, heh, now I think of it it's entirely non-obvious, but the prepare/execute/commit separation is almost entirely about ensuring sanity of, and in the face of, local state [11:37] wallyworld, pretty much all your remote communicatiooin is expected to happpen inside execute [11:38] oh ok [11:38] wallyworld, eg the context.flush stuff [11:38] as you can tell, my uniter foo is low [11:39] wallyworld, no worries, just add angry comments as you encounter non-obvious things [11:39] wallyworld, I have way too *much* history with it so I have very poor judgement re what's oobvious [11:39] fwereade_: so looking at Execute(state State), all i need to do is set the bool and it will all be done [11:39] wallyworld, yeah, I think so [11:40] \o/ [11:40] that makes it easy [11:40] \o/ likewise :) [11:40] and it's great to know now that prepare/execute/commit is about state [11:40] wallyworld, heh [11:40] maybe i should have picked that up [11:41] wallyworld, first I extracted operation.State and .StateFile from the uniter on their own [11:41] wallyworld, and then I gradually moved everything over so that the executor was the only thing with responsibility for writing state [11:41] the new design seems nice for sure [11:42] wallyworld, but it was a slow and piecemeal process and by the time it became *true* that the state-writing was entirely the responsibility of the executor it was "obvious" enough (because I'd been working towards it for weeks) that I didn't think to write it down explicitly [11:42] np :-) [11:42] fwereade_: so, if i move the setting of the state bool to Execute(), this branch won't require much extra work apart from fixing the cmd/juju status tests; the other tests under worker/uniter should all be fine [11:43] wallyworld, I think so, yeah [11:43] great, will do that tomorrow [11:43] wallyworld, cool [11:43] and have it out to early adopters next week [11:43] wallyworld, sweet [11:43] fwereade_: also, i plan only introducing a juju status flag called --v2 [11:43] which will exclude the legacy stuff [11:44] will be much cleaner [11:44] and also tabular by default i thin [11:44] k [11:45] wallyworld, presumably intended to replace juju status in cli2.0? [11:45] yup [11:45] i'll tell early adopters to run juju status --v2 [11:45] wallyworld, wondering whether a flag is really the right way to switch out the implementation [11:46] i guess i could use a feature flag [11:46] that sounds better [11:46] wallyworld, although, well, equally it's really just a new --format [11:46] wallyworld, can I kick you over to thumper to think through how we can do it with minimal disruption to our users *and to ourselves ;p* [11:47] well, not really, it's about excluding ingo [11:47] info [11:47] feature flag i think is consistent with our current approach [11:47] scripts stay the same [11:47] wallyworld, well, how's that different to what --format tabular does? they're both about filtering info to be most useful to out users [11:48] fwereade_: yes, but we want to include the new workload stuff, and exclude the legacy agent-state stuff [11:48] wallyworld, isn't it the same source info in every case? it's just that we present it differently [11:48] all in a nice way, and i'm pretty sure the current tabular output will need to change [11:49] same source, but different inclusions/exclusions as to what's printed [11:49] wallyworld, indeed -- and isn't that what --format does already? given tabular [11:49] maybe i'm thinking of the yaml output too much, but that's really bad with this new stuff [11:50] yes, but in tabular, you still need to choose what to include [11:50] agent-state (legacy) vs worload state vs agent state (new) [11:51] wallyworld, the yaml output is a car crash regardless, I fear -- but it contains ALL THE DATA and is easily machine-readable so it'll always have its uses, it's just a really bad default [11:51] amen to that [11:52] but i'd love to still exclude the legacy stuff for Juju 2.0 [11:52] hence the notion of a feature flag to get 2.0 output today [11:52] for all formats - tabuar, yaml, json [11:52] so people don't rely on deprecated fields [11:53] that will disappear in 2.0 [11:53] wallyworld, agreed, but something about feature-flagging it makes me twitchy [11:53] so the alternative is a --v2 flag to status [11:53] my first suggestion [11:54] remember - we're talking early adopters here [11:54] they can deal with it, whether ff or --v2 [11:54] wallyworld, right, but we'll also want to make it available to normal people in advance of releasing cli2.0 [11:55] fwereade_: what, you saying early adopters aren't "normal"? :-P [11:55] wallyworld, the solution now is I agree not very important *except* that we'll likely keep using the same one in future, because inertia [11:55] wallyworld, ;p [11:55] fwereade_: so, if i were i user, i would i think prefer a feature flag- keeps the CLI syntax the same [11:56] wallyworld, anyway in the interest of completeness the other alternative is a separate "status2" command, vs a feature flag [11:56] yuk, not a status2 please [11:56] wallyworld, the trouble with feature flags is that we can't change them live, so we lock out everyone with a pre-existing environment [11:57] they can be changed live - anyway, in this case, it's purely client side [11:57] we will still ship ALL THE DATA to the CLI [11:57] it's just how it's presented that will change [11:58] wallyworld, heh, they were meant to be immutable per environment exactly so we didn't have the option to abuse them like this [11:58] maybe i'm wrong with the change bit [11:58] i thought you could [11:58] but, first time for everything :-P [11:58] i think you are right [11:59] but if they are ENV variable, then we can change for client [11:59] in this case, server side won't use this feature flag [11:59] i think we can do it that way, maybe not [11:59] i though the client would check the env var first [12:00] wallyworld, probably it does, yeah [12:00] hence the user could toggle [12:00] i'll check anyway, and this will be done after i land the current work [12:01] dimitern: commented on http://reviews.vapour.ws/r/1282/ [12:01] wallyworld, yeah, I'm not convinced by anything either of us have said here really :) [12:02] jam, thanks, just reading it [12:02] wallyworld, would you talk it through with thumper, who has had cli2.0 more directly on his mind? [12:02] sure, will do [12:02] wallyworld, I bet he knows what we should do ;) [12:02] :-) [12:02] jam, the underlying problem is not easy to fix as it involves changes in several places [12:03] * TheMue steps out for a moment, bbiab [12:03] jam, hence I decided to fix GCE and defer the rest to a separate bug fix [12:03] fwereade_: thanks for input on implementation, i'll adjust the approach and look forward to getting this work comitted [12:03] jam, but the proposed GCE fix will still work after the "proper fix" lands [12:04] wallyworld, cheers :) [12:04] dimitern: so are we missing the opportunity to do a correct fix? [12:05] dimitern: put another way, if it works will people ever be bothered to do the right thing. [12:05] jam, I don't think we're missing anything, it's just a gradual improvement [12:10] dimitern: so I added another review, I'm curious about isStateServer [12:10] jam, cool, just replied btw [12:10] and then another thought, do we have to worry about cleaning up at all? Given the original post that destroy-environment was failing [12:10] or was that just "couldn't contact state" [12:11] jam, no, that's another issue - GCE not finding the machines it's tagging as juju--machine-X [12:12] jam, but it's not always not finding them, it seems like a race or improper query [12:22] * dimitern steps out for a while [13:18] Bug #1408459 changed: pingerSuite tests consistenly fail on trusty+386 and vivid+amd64

[13:30] cleaning my keyboard [13:30] managed to reboot by mistake... [13:33] fwereade_: can you point me to the uniter code that invokes Run(ctx) on the hook tool commands [13:34] wallyworld, runner/jujuc/server.go I think? [13:35] fwereade_: ok, so that invokes cmd.Main() which ultimately gets to Run(ctx) I guess [13:35] wallyworld, yeah [13:36] fwereade_: i'm figuring out at what point it's sensible to update local state [13:36] as we're not in a hook and so Execute(state) isn't in play [13:37] wallyworld, sorry, ECONTEXT [13:37] wallyworld, local state distinct from the did-set-status flag? [13:37] fwereade_: so from conversation before, did-set-status flag is persisted in uniter local state [13:38] when executing hooks, state is persisted at the end of a hook in Commit() [13:38] but here a hook tool is being run [13:38] not a hook [13:39] wallyworld, isn't there a SetStatusy method on Context? which can then just store the flag, and then runHook.Execute can pull that out of the context (because it cares) and all the other runnery ops can just not bother? [13:39] wallyworld, a hook tool is always going to be invoked inside a runner, isn't it? [13:40] fwereade_: so we have uniter.runner.Runner [13:41] and that interface has a Context [13:41] which embeds a jujuc.Context [13:41] but i can't see access to State anywhere in any of that [13:43] there's RunHook() and RunAction() [13:43] but the RunCommands() seems to execute a script [13:43] rather than a hook tool command [13:43]