| ericsnow | cherylj: I've gotta run; others should be able to help keep your merge train moving though :) | 00:01 |
|---|---|---|
| cherylj | thanks, ericsnow! | 00:02 |
| === kadams54 is now known as kadams54-away | ||
| axw | 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 |
| axw | cherylj: I'm referring to, e.g. "This package deals with Juju names." | 01:04 |
| cherylj | axw: The answer I got when I asked was that it's a courtesy / convention and not a hard requirement | 01:05 |
| axw | cherylj: thanks | 01:05 |
| cherylj | np! :) | 01:05 |
| axw | wallyworld: reviewed status-get | 01:27 |
| wallyworld | axw: tyvm | 01:27 |
| axw | wallyworld: can you please add "hackers" to the replicaset repo? | 01:48 |
| wallyworld | sure | 01:48 |
| wallyworld | done | 01:49 |
| axw | ta | 01:49 |
| axw | 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:50 |
| wallyworld | axw: licence file not quite right - see the recent commits to 1.22 or master i think | 01:58 |
| wallyworld | you don't need the whole file - just a copyright statement and a reference to the licence | 01:59 |
| axw | wallyworld: which repo? I copied this from juju/txn | 01:59 |
| wallyworld | axw: https://github.com/juju/juju/blob/1.22/LICENCE | 01:59 |
| wallyworld | axw: also, status-get updated, ptal when free | 01:59 |
| axw | wallyworld: possibly different for that, because we don't have an exception to AGPL | 02:00 |
| axw | wallyworld: we do for LGPL though | 02:00 |
| axw | looking | 02:01 |
| wallyworld | axw: i oasted a link above to the licence file recently added to 1.22 for juju | 02:03 |
| axw | wallyworld: yes... that is AGPL | 02:05 |
| axw | wallyworld: the replicaset one will be LGPL+exception | 02:05 |
| axw | wallyworld: just responded, sorry I realised I should hit shipit... I'll just take another look over | 02:07 |
| axw | wallyworld: done | 02:09 |
| axw | thumper: is the charm repo really meant to be AGPL? | 02:10 |
| thumper | axw: I'm not sure, but since it wasn't a change, I let it through | 02:10 |
| thumper | personally I would have thought lgpl | 02:11 |
| axw | ah ok | 02:11 |
| axw | thumper: do you know what the deal is with including the full copyright text? | 02:11 |
| axw | I copied from juju/txn, which has the full text for LGPL. the AGPL ones are abridged | 02:11 |
| thumper | axw: no, was looking at the bug | 02:14 |
| ericsnow | anastasiamac_: FYI, I found the following failure on vivid: #1436397 | 03:04 |
| mup | Bug #1436397: map-order sensitive test in md/juju/storage needs to be fixed <map-order> <juju-core:Triaged> <https://launchpad.net/bugs/1436397> | 03:04 |
| anastasiamac_ | ericsnow: i saw :( | 03:04 |
| anastasiamac_ | ericsnow: will aim to fix today... later on... sometime :D | 03:04 |
| ericsnow | anastasiamac_: should be pretty easy to fix | 03:04 |
| ericsnow | anastasiamac_: sound good :) | 03:04 |
| anastasiamac_ | ericsnow: yep :D | 03:04 |
| anastasiamac_ | 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 |
| ericsnow | anastasiamac_: nah, it's about 9pm (happened to be following up on a few little things) | 03:06 |
| anastasiamac_ | ericsnow: 9pm is an ok office hour? :D | 03:07 |
| ericsnow | anastasiamac_: well, for our team I tend to have to follow-up on stuff in the evening (but try to limit myself) | 03:07 |
| anastasiamac_ | ericsnow: :) | 03:09 |
| anastasiamac_ | ericsnow: map ordering is my 2nd best nemesis :D | 03:09 |
| wwitzel3 | can anyone remind me of the process of connecting to mongod when running local provider? | 03:11 |
| wwitzel3 | via the mongo client | 03:11 |
| ericsnow | axw: thanks for the review | 03:18 |
| ericsnow | 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 |
| axw | ericsnow: yes, will do, thanks | 03:18 |
| ericsnow | axw: much appreciated | 03:19 |
| axw | 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:21 |
| ericsnow | axw: sweet | 03:22 |
| ericsnow | axw: keep the feedback coming :) | 03:22 |
| wallyworld | axw: here's the status-set if you have a chance at some point http://reviews.vapour.ws/r/1279/ | 03:26 |
| axw | wallyworld: yup, just opened it | 03:26 |
| ericsnow | wallyworld: could you (or your delegate) follow up on #1434437 | 03:27 |
| mup | Bug #1434437: juju restore failed with "error: cannot update machines: machine update failed: ssh command failed: " <backup-restore> <maas-provider> <juju-core:Invalid> <juju-core 1.22:Incomplete by ericsnowcurrently> <https://launchpad.net/bugs/1434437> | 03:27 |
| ericsnow | wallyworld: the reporter is about your TZ | 03:27 |
| axw | wallyworld: couple of questions on the review | 03:38 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | axw: thanks for review, issues fixed | 03:53 |
| axw | ta, looking | 03:53 |
| axw | wallyworld: btw, what will go in the "data"? | 03:54 |
| axw | modification time? | 03:54 |
| * axw checks spec | 03:54 | |
| axw | wallyworld: LGTM, added a comment as food for thought | 03:57 |
| axw | -_- | 03:58 |
| * axw wishes wallyworld would get a refresh already | 03:58 | |
| axw | wallyworld: LGTM, added a comment as food for thought | 03:59 |
| wallyworld | sure, np | 03:59 |
| wallyworld | ty | 03:59 |
| wallyworld | axw: updated time will be shown, but it's not implemented yet | 04:01 |
| wallyworld | what we currently have is what's displayed | 04:01 |
| axw | wallyworld: from my glance over the spec I didn't see anything other than status, message and update time in the output | 04:02 |
| axw | wallyworld: so my question is, should we really be splatting out a k/v map, or should we just extract the update time | 04:02 |
| mup | Bug #1436655 was opened: gce provider should stop using deprecated zone europe-west1-a <gce-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1436655> | 04:05 |
| thumper | 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:09 |
| thumper | also, any reviewer... http://reviews.vapour.ws/r/1280/ | 04:10 |
| axw | wallyworld: should "juju cached-images" work with the local provider? | 04:52 |
| axw | wallyworld: cos it doesn't | 04:52 |
| wallyworld | axw: yes | 04:53 |
| wallyworld | it did when i last tested it | 04:53 |
| wallyworld | as that's how it was developed | 04:53 |
| wallyworld | what's it doing (or not)? | 04:53 |
| axw | wallyworld: I see. | 04:53 |
| axw | juju cached-images list | 04:53 |
| axw | no matching images found | 04:53 |
| axw | wallyworld: ^ | 04:53 |
| wallyworld | hmmm | 04:53 |
| axw | doesn't matter if I specify a filter or not | 04:54 |
| wallyworld | i reckon JES has stuffed it up | 04:54 |
| wallyworld | there's an environ filter or something | 04:54 |
| wallyworld | just a guess | 04:54 |
| axw | mk | 04:54 |
| axw | wallyworld: also, I set "allow-lxc-loop-mounts:true" in environments.yaml but "loop" still doesn't work on local :( | 04:55 |
| wallyworld | oh, what does the lxc.conf have in it? | 04:55 |
| wallyworld | i didn't test end-end cause at the time, it wasn't working, i just ensured the lxc.conf was correct | 04:56 |
| axw | wallyworld: where's that again? | 04:56 |
| wallyworld | lxc-broker.go maybe, i'll check | 04:57 |
| axw | I mean, where's lxc.conf | 04:57 |
| axw | wallyworld: hum, my container doesn't have an lxc.conf... | 04:58 |
| wallyworld | hmmm, /var/lib/lxc/containers/... i would have thought | 04:58 |
| wallyworld | there's 2 files we generate i think | 04:59 |
| axw | ok, I'll go digging | 04:59 |
| wallyworld | config and something else i can't recall | 04:59 |
| wallyworld | axw: i think it's /var/lib/lxc/<container-name>/config | 05:04 |
| dimitern | wallyworld, axw, if you're not using lxc clone, the generated lxc.conf should be in /var/lib/juju/containers/<name>/, otherwise only the template lxc container has lxc.conf, the rest use the run-time config in /var/lib/lxc/<name>/config | 05:05 |
| axw | I see | 05:05 |
| wallyworld | dimitern: so i was half right :-) | 05:05 |
| dimitern | :) | 05:06 |
| wallyworld | or fully right for me as i don't use templates | 05:06 |
| axw | wallyworld: welp, the aa bits aren't making it into the config file... will keep digging | 05:06 |
| wallyworld | ok, sorry it's not working | 05:06 |
| dimitern | axw, I guess you are using lxc-clone: true then? | 05:07 |
| axw | dimitern: no | 05:07 |
| axw | dimitern: it's not in the template either, in any case | 05:07 |
| dimitern | axw, ah, ok | 05:08 |
| axw | wallyworld: ah, I know what happened. loop is "dynamic", so there are no volumes passed to StartInstance | 05:12 |
| axw | wallyworld: I think we just need to enable it if the config attr is set | 05:12 |
| wallyworld | ah yes | 05:12 |
| tasdomas | hi | 07:48 |
| tasdomas | I have a few questions about windows support in juju-core, especially the uniter | 07:48 |
| tasdomas | in https://github.com/juju/juju/blob/master/worker/uniter/paths_test.go#L83 | 07:49 |
| tasdomas | will those tests work in windows? | 07:49 |
| tasdomas | are they supposed to? | 07:49 |
| Muntaner | hello guys | 09:09 |
| Muntaner | is there a way to get from CLI the ip address of a service? | 09:09 |
| Muntaner | I mean, I can do it with stat - but need to do greps and cuts to get just the IP | 09:09 |
| Muntaner | (I need it in a script) | 09:09 |
| dimitern | Muntaner, try something like: addr=`juju run --unit myunit/1 unit-get private-address` | 09:23 |
| Muntaner | dimitern, this just executes the unit-get command? | 09:25 |
| Muntaner | dimitern, just seen the man - yes, thanks :) | 09:25 |
| dimitern | Muntaner, yeah | 09:26 |
| dimitern | np :) | 09:26 |
| Muntaner | dimitern, which name should I specify for the 0 machine? | 09:32 |
| dimitern | Muntaner, use --machine 0 | 09:32 |
| dimitern | Muntaner, but didn't you want the address of the unit? | 09:34 |
| Muntaner | dimitern, no, I need the floating IP of the "bootstraper" machine | 09:35 |
| Muntaner | dimitern, I strangely get a "unrecognized argoment: public-address" with the unit-get | 09:35 |
| Muntaner | unrecognized args* | 09:35 |
| Muntaner | maybe should I specify the location of the unit-get command? | 09:36 |
| dimitern | Muntaner, ah, ok - you can't get the floating IP like this (from the machine itself) | 09:37 |
| dimitern | Muntaner, because it's something the cloud provider knows, not the machine itself | 09:37 |
| Muntaner | dimitern, aw. Isn't there any other option? | 09:38 |
| dimitern | 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:42 |
| mup | Bug #1436766 was opened: juju run fails on manually provisioned instance <juju-core:New> <https://launchpad.net/bugs/1436766> | 09:54 |
| rogpeppe | 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:54 |
| rogpeppe | 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:55 |
| rogpeppe | ericsnow, jam: ^ | 09:56 |
| dimitern | rogpeppe, where's that? | 09:58 |
| rogpeppe | dimitern: where's what? | 09:58 |
| dimitern | rogpeppe, the import - which branch, file? | 09:59 |
| rogpeppe | dimitern: package github.com/juju/juju/service, file fake.go | 09:59 |
| dimitern | rogpeppe, hmm that's a good catch! | 09:59 |
| dimitern | rogpeppe, it should've been in a service/testing subpackage | 10:00 |
| rogpeppe | dimitern: yes | 10:00 |
| mattyw | rogpeppe, dimitern I can do that now if you're busy | 10:00 |
| rogpeppe | dimitern: and i think there should be some test that would catch that - it's not an uncommon mistake | 10:00 |
| mattyw | rogpeppe, dimitern I'm still trying to to work out how I'm going to arrange my day | 10:00 |
| mattyw | rogpeppe, dimitern this would be a nice distraction | 10:01 |
| dimitern | rogpeppe, mattyw, sorry my standup is just starting | 10:01 |
| rogpeppe | dimitern: np | 10:01 |
| rogpeppe | dimitern: perhaps you could mention it | 10:01 |
| dimitern | rogpeppe, will do | 10:01 |
| dimitern | actually it's the weekly team meeting now | 10:01 |
| rogpeppe | dimitern: there's also github.com/juju/juju/service/systemd | 10:08 |
| rogpeppe | dimitern: testing.go in there | 10:08 |
| dimitern | voidspace, dooferlad, TheMue, I've joined our standup | 10:19 |
| mattyw | wallyworld, I like the pep talks - thanks. enjoy your wine | 10:19 |
| voidspace | dimitern: we've all stayed in the last one | 10:19 |
| voidspace | dimitern: we're joining you though... | 10:19 |
| wallyworld | mattyw: hey matty, no worries, sorry i didn't mention metric first up | 10:19 |
| mattyw | 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 |
| wallyworld | mattyw: yeah, i'm sure i left off at least one or two other items :-) | 10:20 |
| wallyworld | fwereade: hey, you around? | 10:53 |
| fwereade | wallyworld, heyhey | 11:00 |
| wallyworld | 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 |
| wallyworld | i also have the new branch mostly complete, except for more tests etc | 11:01 |
| wallyworld | would be great if you could take a look | 11:02 |
| wallyworld | https://github.com/juju/juju/compare/juju:master...wallyworld:unit-agent-state?expand=1 | 11:02 |
| wallyworld | i had to expand an interface or two | 11:02 |
| wallyworld | to allow the setting of an attribute in uniter state from a hook context | 11:02 |
| wallyworld | worker uniter tests all pass | 11:02 |
| wallyworld | got to add a few more potentially, and also look to see if cmd/juju/status tests pass (which they won't) | 11:03 |
| fwereade | wallyworld, yeah, I must say that OperationStateAccessor raises an eyebrow or two | 11:05 |
| wallyworld | 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:06 |
| wallyworld | to record that the set status call happened | 11:07 |
| fwereade | wallyworld, right, but operation state used to be exclusively set by the executor, taking advice from the operations that actually executed | 11:07 |
| fwereade | wallyworld, now... anything that can see an operation can do wtf it likes to state | 11:07 |
| wallyworld | fwereade: operations controller by the uniter | 11:07 |
| wallyworld | fwereade: so i could restrict the method to only allow that specific bool to be set | 11:08 |
| wallyworld | unless you have another suggestion? | 11:08 |
| wallyworld | bear in mind this is more or less my first foray into the uniter code, so may be missing a few key tings | 11:09 |
| fwereade | sure, I'm thinking about it | 11:11 |
| wallyworld | i can hear the cogs turning :-) | 11:12 |
| fwereade | wallyworld, sorry, I'm being dense, I can't follow the chain that causes a different state to be written or not | 11:12 |
| fwereade_ | wallyworld, dammit, what was the last think you saw me say? | 11:30 |
| === beisner- is now known as beisner | ||
| wallyworld | <fwereade> wallyworld, but passing operationExecutor into the runner factory feels wrong | 11:30 |
| wallyworld | fwereade: what was the last thing you saw me say? | 11:30 |
| dimitern | ericsnow, natefinch, please have a look at this when you can http://reviews.vapour.ws/r/1282/ - fixes bug 1436191 | 11:31 |
| wallyworld | [21:15:02] <wallyworld> but till now, uniter state has been controlled by the executor which is running the hooks | 11:31 |
| wallyworld | [21:15:26] <wallyworld> yes, it did feel wrong, hence i tried to use an interface that restricted the exposure | 11:31 |
| wallyworld | [21:15:37] <wallyworld> i didn't immediately see another way to do it | 11:31 |
| wallyworld | [21:16:19] <wallyworld> fwereade: so | 11:31 |
| wallyworld | [21:16:35] <wallyworld> OperationsStateAccessor *ony* exposes the CharmSetStatus() method | 11:31 |
| wallyworld | [21:16:38] <wallyworld> only | 11:31 |
| mup | Bug #1436191: gce: bootstrap instance has no network rule for API <firewall> <gce-provider> <juju-core:In Progress by dimitern> <juju-core 1.23:In Progress by dimitern> <https://launchpad.net/bugs/1436191> | 11:31 |
| wallyworld | [21:17:08] <wallyworld> hence even though we pass in the executor, the code running in the jujuc context can only do that one thing | 11:31 |
| wallyworld | [21:17:29] <wallyworld> i kept telling myself that was "acceptable" | 11:31 |
| wallyworld | [21:17:59] --> rvba` (~rvba@culvain.gromper.net) has joined #juju-dev | 11:31 |
| wallyworld | [21:18:10] <wallyworld> that CharmSetStatus() method only sets that one bool in uniter state | 11:31 |
| wallyworld | [21:18:30] <wallyworld> so the code in a jujuc context can't do any harm as such | 11:31 |
| fwereade_ | wallyworld, essay in http://paste.ubuntu.com/10683319/ | 11:32 |
| wallyworld | looking | 11:32 |
| fwereade_ | wallyworld, but I think I was only just figuring out the real issue | 11:32 |
| fwereade_ | wallyworld, namely that status-set-related state changes should only happen in hooks | 11:32 |
| fwereade_ | 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 |
| wallyworld | fwereade_: a hook tool can be called outside a a hook | 11:33 |
| fwereade_ | wallyworld, actions, juju-run, whatever | 11:33 |
| wallyworld | ah right juju-run, yes | 11:33 |
| fwereade_ | wallyworld, (and, hmm, debug-hooks -- how does that affect the story?) | 11:33 |
| fwereade_ | wallyworld, but anyway I *think* that runHook.Execute is the only thing that needs to know whether status-set was called | 11:34 |
| fwereade_ | wallyworld, and that's always got access to a context | 11:35 |
| wallyworld | fwereade_: i was thinking, perhaps wrongly, that we'd only want to set the workload status in commit() | 11:35 |
| wallyworld | cause i was thinking it was like a db op - there could be a rollback | 11:35 |
| wallyworld | so we run execute, and if all went well, we commit | 11:36 |
| wallyworld | and that's when we need to set the workload status to unknown if status-set was not called | 11:36 |
| wallyworld | or to terminated if stop was called | 11:36 |
| wallyworld | fwereade_: and i also thought hook tools were serialised with hooks | 11:37 |
| fwereade_ | 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 |
| fwereade_ | wallyworld, pretty much all your remote communicatiooin is expected to happpen inside execute | 11:37 |
| wallyworld | oh ok | 11:38 |
| fwereade_ | wallyworld, eg the context.flush stuff | 11:38 |
| wallyworld | as you can tell, my uniter foo is low | 11:38 |
| fwereade_ | wallyworld, no worries, just add angry comments as you encounter non-obvious things | 11:39 |
| fwereade_ | wallyworld, I have way too *much* history with it so I have very poor judgement re what's oobvious | 11:39 |
| wallyworld | fwereade_: so looking at Execute(state State), all i need to do is set the bool and it will all be done | 11:39 |
| fwereade_ | wallyworld, yeah, I think so | 11:39 |
| wallyworld | \o/ | 11:40 |
| wallyworld | that makes it easy | 11:40 |
| fwereade_ | \o/ likewise :) | 11:40 |
| wallyworld | and it's great to know now that prepare/execute/commit is about state | 11:40 |
| fwereade_ | wallyworld, heh | 11:40 |
| wallyworld | maybe i should have picked that up | 11:40 |
| fwereade_ | wallyworld, first I extracted operation.State and .StateFile from the uniter on their own | 11:41 |
| fwereade_ | wallyworld, and then I gradually moved everything over so that the executor was the only thing with responsibility for writing state | 11:41 |
| wallyworld | the new design seems nice for sure | 11:41 |
| fwereade_ | 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 |
| wallyworld | np :-) | 11:42 |
| wallyworld | 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:42 |
| fwereade_ | wallyworld, I think so, yeah | 11:43 |
| wallyworld | great, will do that tomorrow | 11:43 |
| fwereade_ | wallyworld, cool | 11:43 |
| wallyworld | and have it out to early adopters next week | 11:43 |
| fwereade_ | wallyworld, sweet | 11:43 |
| wallyworld | fwereade_: also, i plan only introducing a juju status flag called --v2 | 11:43 |
| wallyworld | which will exclude the legacy stuff | 11:43 |
| wallyworld | will be much cleaner | 11:44 |
| wallyworld | and also tabular by default i thin | 11:44 |
| wallyworld | k | 11:44 |
| fwereade_ | wallyworld, presumably intended to replace juju status in cli2.0? | 11:45 |
| wallyworld | yup | 11:45 |
| wallyworld | i'll tell early adopters to run juju status --v2 | 11:45 |
| fwereade_ | wallyworld, wondering whether a flag is really the right way to switch out the implementation | 11:45 |
| wallyworld | i guess i could use a feature flag | 11:46 |
| wallyworld | that sounds better | 11:46 |
| fwereade_ | wallyworld, although, well, equally it's really just a new --format | 11:46 |
| fwereade_ | 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:46 |
| wallyworld | well, not really, it's about excluding ingo | 11:47 |
| wallyworld | info | 11:47 |
| wallyworld | feature flag i think is consistent with our current approach | 11:47 |
| wallyworld | scripts stay the same | 11:47 |
| fwereade_ | 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:47 |
| wallyworld | fwereade_: yes, but we want to include the new workload stuff, and exclude the legacy agent-state stuff | 11:48 |
| fwereade_ | wallyworld, isn't it the same source info in every case? it's just that we present it differently | 11:48 |
| wallyworld | all in a nice way, and i'm pretty sure the current tabular output will need to change | 11:48 |
| wallyworld | same source, but different inclusions/exclusions as to what's printed | 11:49 |
| fwereade_ | wallyworld, indeed -- and isn't that what --format does already? given tabular | 11:49 |
| wallyworld | maybe i'm thinking of the yaml output too much, but that's really bad with this new stuff | 11:49 |
| wallyworld | yes, but in tabular, you still need to choose what to include | 11:50 |
| wallyworld | agent-state (legacy) vs worload state vs agent state (new) | 11:50 |
| fwereade_ | 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 |
| wallyworld | amen to that | 11:51 |
| wallyworld | but i'd love to still exclude the legacy stuff for Juju 2.0 | 11:52 |
| wallyworld | hence the notion of a feature flag to get 2.0 output today | 11:52 |
| wallyworld | for all formats - tabuar, yaml, json | 11:52 |
| wallyworld | so people don't rely on deprecated fields | 11:52 |
| wallyworld | that will disappear in 2.0 | 11:53 |
| fwereade_ | wallyworld, agreed, but something about feature-flagging it makes me twitchy | 11:53 |
| wallyworld | so the alternative is a --v2 flag to status | 11:53 |
| wallyworld | my first suggestion | 11:53 |
| wallyworld | remember - we're talking early adopters here | 11:54 |
| wallyworld | they can deal with it, whether ff or --v2 | 11:54 |
| fwereade_ | wallyworld, right, but we'll also want to make it available to normal people in advance of releasing cli2.0 | 11:54 |
| wallyworld | fwereade_: what, you saying early adopters aren't "normal"? :-P | 11:55 |
| fwereade_ | 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 |
| fwereade_ | wallyworld, ;p | 11:55 |
| wallyworld | fwereade_: so, if i were i user, i would i think prefer a feature flag- keeps the CLI syntax the same | 11:55 |
| fwereade_ | wallyworld, anyway in the interest of completeness the other alternative is a separate "status2" command, vs a feature flag | 11:56 |
| wallyworld | yuk, not a status2 please | 11:56 |
| fwereade_ | 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:56 |
| wallyworld | they can be changed live - anyway, in this case, it's purely client side | 11:57 |
| wallyworld | we will still ship ALL THE DATA to the CLI | 11:57 |
| wallyworld | it's just how it's presented that will change | 11:57 |
| fwereade_ | 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 |
| wallyworld | maybe i'm wrong with the change bit | 11:58 |
| wallyworld | i thought you could | 11:58 |
| wallyworld | but, first time for everything :-P | 11:58 |
| wallyworld | i think you are right | 11:58 |
| wallyworld | but if they are ENV variable, then we can change for client | 11:59 |
| wallyworld | in this case, server side won't use this feature flag | 11:59 |
| wallyworld | i think we can do it that way, maybe not | 11:59 |
| wallyworld | i though the client would check the env var first | 11:59 |
| fwereade_ | wallyworld, probably it does, yeah | 12:00 |
| wallyworld | hence the user could toggle | 12:00 |
| wallyworld | i'll check anyway, and this will be done after i land the current work | 12:00 |
| jam | dimitern: commented on http://reviews.vapour.ws/r/1282/ | 12:01 |
| fwereade_ | wallyworld, yeah, I'm not convinced by anything either of us have said here really :) | 12:01 |
| dimitern | jam, thanks, just reading it | 12:02 |
| fwereade_ | wallyworld, would you talk it through with thumper, who has had cli2.0 more directly on his mind? | 12:02 |
| wallyworld | sure, will do | 12:02 |
| fwereade_ | wallyworld, I bet he knows what we should do ;) | 12:02 |
| wallyworld | :-) | 12:02 |
| dimitern | jam, the underlying problem is not easy to fix as it involves changes in several places | 12:02 |
| * TheMue steps out for a moment, bbiab | 12:03 | |
| dimitern | jam, hence I decided to fix GCE and defer the rest to a separate bug fix | 12:03 |
| wallyworld | fwereade_: thanks for input on implementation, i'll adjust the approach and look forward to getting this work comitted | 12:03 |
| dimitern | jam, but the proposed GCE fix will still work after the "proper fix" lands | 12:03 |
| fwereade_ | wallyworld, cheers :) | 12:04 |
| jam | dimitern: so are we missing the opportunity to do a correct fix? | 12:04 |
| jam | dimitern: put another way, if it works will people ever be bothered to do the right thing. | 12:05 |
| dimitern | jam, I don't think we're missing anything, it's just a gradual improvement | 12:05 |
| jam | dimitern: so I added another review, I'm curious about isStateServer | 12:10 |
| dimitern | jam, cool, just replied btw | 12:10 |
| jam | 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 |
| jam | or was that just "couldn't contact state" | 12:10 |
| dimitern | jam, no, that's another issue - GCE not finding the machines it's tagging as juju-<uuid>-machine-X | 12:11 |
| dimitern | jam, but it's not always not finding them, it seems like a race or improper query | 12:12 |
| * dimitern steps out for a while | 12:22 | |
| mup | Bug #1408459 changed: pingerSuite tests consistenly fail on trusty+386 and vivid+amd64 <ci> <i386> <intermittent-failure> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.23:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1408459> | 13:18 |
| voidspace | cleaning my keyboard | 13:30 |
| voidspace | managed to reboot by mistake... | 13:30 |
| wallyworld | fwereade_: can you point me to the uniter code that invokes Run(ctx) on the hook tool commands | 13:33 |
| fwereade_ | wallyworld, runner/jujuc/server.go I think? | 13:34 |
| wallyworld | fwereade_: ok, so that invokes cmd.Main() which ultimately gets to Run(ctx) I guess | 13:35 |
| fwereade_ | wallyworld, yeah | 13:35 |
| wallyworld | fwereade_: i'm figuring out at what point it's sensible to update local state | 13:36 |
| wallyworld | as we're not in a hook and so Execute(state) isn't in play | 13:36 |
| fwereade_ | wallyworld, sorry, ECONTEXT | 13:37 |
| fwereade_ | wallyworld, local state distinct from the did-set-status flag? | 13:37 |
| wallyworld | fwereade_: so from conversation before, did-set-status flag is persisted in uniter local state | 13:37 |
| wallyworld | when executing hooks, state is persisted at the end of a hook in Commit() | 13:38 |
| wallyworld | but here a hook tool is being run | 13:38 |
| wallyworld | not a hook | 13:38 |
| fwereade_ | 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 |
| fwereade_ | wallyworld, a hook tool is always going to be invoked inside a runner, isn't it? | 13:39 |
| wallyworld | fwereade_: so we have uniter.runner.Runner | 13:40 |
| wallyworld | and that interface has a Context | 13:41 |
| wallyworld | which embeds a jujuc.Context | 13:41 |
| wallyworld | but i can't see access to State anywhere in any of that | 13:41 |
| wallyworld | there's RunHook() and RunAction() | 13:43 |
| wallyworld | but the RunCommands() seems to execute a script | 13:43 |
| wallyworld | rather than a hook tool command | 13:43 |
| fwereade_ | wallyworld, runner/factory.go:263 relevant? | 13:43 |
| fwereade_ | wallyworld, may be confusion there? hooks and actions are just scripts | 13:43 |
| fwereade_ | wallyworld, hook tools are the things we set up for thoose scripts to use, be they hooks or actions or just arbitrary ash or powershell or whatever | 13:44 |
| wallyworld | right, but i want to access the hook tool execution at the point where the uniter is in play | 13:44 |
| wallyworld | ie the server side of the script call back into the uniter | 13:44 |
| fwereade_ | wallyworld, let me try to restate your problem | 13:45 |
| fwereade_ | wallyworld, you're in some implementation of jujuc.Context, specifically runner.HookContext, and you're in the middle of setting status | 13:46 |
| fwereade_ | wallyworld, you have an api conn, so setting it on the state server is easy | 13:46 |
| fwereade_ | wallyworld, but you want to be sure that the uniter itself knows it's happened | 13:46 |
| wallyworld | fwereade_: it's a jujuc.Context, not sure if that's a HookContext | 13:47 |
| fwereade_ | wallyworld, HookContext is (at the moment) the one useful concrete implementation of jujuc.Context | 13:47 |
| wallyworld | yes, uniter needs to know it happened, so that s=at the end of the start hook, it can do something | 13:47 |
| wallyworld | i see, ok, i clearly forgot that HookContext was a jujuc.Context | 13:48 |
| wallyworld | but yes, of course it is | 13:48 |
| fwereade_ | wallyworld, ok, so HookContext is not just a jujuc.Context | 13:48 |
| mup | Bug #1423372 changed: juju-br0 is not configured correctly on maas machines without ethX interfaces <cloud-installer> <jujud> <maas-provider> <network> <juju-core:Fix Released> <https://launchpad.net/bugs/1423372> | 13:48 |
| wallyworld | i added that OperationsStateAccessor to it | 13:48 |
| fwereade_ | wallyworld, it's also a runner.Context | 13:48 |
| fwereade_ | wallyworld, and it's via runner.Context that the ops should be able to get in and find out whether the flag is set | 13:49 |
| fwereade_ | wallyworld, those two should be better separated, I freely admit | 13:49 |
| fwereade_ | wallyworld, none of that code is *good*, it's just better than it was in some respects ;) | 13:49 |
| sinzui | dimitern, can you ask someone to read the pastebin links to the logs in this bug https://bugs.launchpad.net/juju-core/+bug/1435644 > I cannot triage it. I think juju is looking for image-streams *after* the instance is brought up. | 13:50 |
| mup | Bug #1435644: private cloud:( environment is openstack )index file has no data for cloud <juju-core:New> <https://launchpad.net/bugs/1435644> | 13:50 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | fwereade_: understood | 13:50 |
| wallyworld | fwereade_: so i'm still at the point where the runner Context has a SetUnitStatus() API, fine, but i need to be at a layer above that to update the uniter state | 13:51 |
| fwereade_ | wallyworld, but does that generally make sense? the HookContext isn't in the business of assuming it's being run by a uniter or anything like that | 13:51 |
| fwereade_ | wallyworld, it *is* in the business of knowing when status-set has been called | 13:51 |
| fwereade_ | wallyworld, because in *some* contexts its clients want to know about that | 13:52 |
| wallyworld | fwereade_: so how does HookContext know if status-set has been called when it doesn't seem to have access to uniter State | 13:52 |
| fwereade_ | wallyworld, but it's a matter of recording a flag on SetStatus, and exposing it via a new runner.Context method that lets the op find out whether it happpened or not after the fact | 13:52 |
| fwereade_ | wallyworld, whether or not anyone invoked whatever the SetStatus method on jujuc.Context | 13:52 |
| wallyworld | but how is that flag persisted into local uniter State? | 13:52 |
| === kadams54-away is now known as kadams54 | ||
| fwereade_ | wallyworld, the runHook operation runs the runner, asks for the context, asks the context if status-set was called; and if so sets that field on the State it returns to the executor | 13:53 |
| wallyworld | i can easily set a flag on HookContext, but it needs to be persisted | 13:53 |
| fwereade_ | wallyworld, but only sometimes, and that's not HookContext's responsibility | 13:54 |
| wallyworld | but it's not a hook we are running but a hook tool | 13:54 |
| fwereade_ | wallyworld, any time we execute user code we do it in a hook context, don't we? | 13:54 |
| wallyworld | so how does runHook come into it - runHook runs hooks right? not hook tools? | 13:54 |
| fwereade_ | wallyworld, runHook runs hooks, but to do that it needs to set up the runner that runs them, which sets up a context that's responsible for providing the implementation of the tools for jujuc.Server | 13:55 |
| fwereade_ | wallyworld, most of that is hidden away inside the runner.Factory | 13:55 |
| wallyworld | ok, i'll dig some more. right now we have as a method on HookContext: func (ctx *HookContext) SetUnitStatus(status jujuc.StatusInfo) error {} | 13:56 |
| wallyworld | but inside that method, there's no access to saving state | 13:56 |
| wallyworld | so it needs to be done at a layer above | 13:56 |
| fwereade_ | wallyworld, we mean local uniter state, right? | 13:57 |
| wallyworld | yes | 13:57 |
| fwereade_ | wallyworld, right, it's not HC's responsibility to set uniter state | 13:57 |
| fwereade_ | wallyworld, it shouldn't have the faintest idea what a uniter is ;) | 13:57 |
| wallyworld | yes | 13:57 |
| fwereade_ | wallyworld, but as you say the level up needs to do that | 13:57 |
| fwereade_ | wallyworld, so I think you can just add a .didCallStatusSet field in HookContext | 13:58 |
| wallyworld | so i'm trying to find where i need to be in order to catch the bit that runs the SetUnitStatus() method and which has acess to local state | 13:58 |
| fwereade_ | wallyworld, and a DidCallStatusSet() bool method to runner.Context | 13:58 |
| wallyworld | but that field won't be persisted | 13:58 |
| wallyworld | and it needs to be | 13:58 |
| fwereade_ | wallyworld, and then runHook.Execute can just ask for self.runner.Context().DidCallStatusSet, and it it's true, write it into the state it returns to the executor | 13:58 |
| wallyworld | that won't work will it - it needs to be persisted between hooks | 13:59 |
| wallyworld | as i need to see if set status was called during either Install or Start hooks | 13:59 |
| fwereade_ | wallyworld, what inside a hook behaves differently if status-set has been called or not? | 13:59 |
| fwereade_ | wallyworld, ah right | 13:59 |
| fwereade_ | wallyworld, isn't that even simpler? | 13:59 |
| wallyworld | maybe? | 14:00 |
| fwereade_ | wallyworld, if you only want to check in those hooks, you only need to call DidCallStatusSet() when you're figuring out the state change from running start/install | 14:00 |
| fwereade_ | wallyworld, and runHook knows what hook it's running... | 14:00 |
| wallyworld | so | 14:00 |
| wallyworld | the charm could call status-set inside Install hook | 14:01 |
| wallyworld | but not STart hook | 14:01 |
| wallyworld | and i still need to know that | 14:01 |
| wallyworld | hence the did-it-call-stats-set flag needs to be persisted to local uniter state | 14:01 |
| sinzui | dimitern, natefinch : I am having trouble triaging bug 1436421. I could say it is medium, but maybe a engineer wants more information to know what is really happening | 14:01 |
| mup | Bug #1436421: juju panics after upgrade from 1.18.4 to 1.20.11 <panic> <status> <juju-core:New> <https://launchpad.net/bugs/1436421> | 14:01 |
| fwereade_ | wallyworld, really? isn't a charm that does that explicitly telling you that it knows about status but nothing happened in the start hook to cause it to change? | 14:02 |
| fwereade_ | wallyworld, right, local unitrer state is controlled by what the op methods returnn | 14:02 |
| wallyworld | fwereade_: well, i think we need to cater for that use case, in the case where start hook is a noop | 14:02 |
| wallyworld | fwereade_: so, i still need to find where in the uniter code there's 1. access to local state to save flag, 2. access to hook tools that are run so that flag can be set | 14:04 |
| wallyworld | not hooks via Execute() et al but hook tools | 14:04 |
| wallyworld | and then Install can run, for example, set the flag if needed, and Start can see that the flag was set | 14:05 |
| wallyworld | the flag will be set in stats-set is invoked inside Install | 14:05 |
| fwereade_ | wallyworld, so, I think that the runHook operation has everything you need... | 14:05 |
| fwereade_ | wallyworld, it has access to the context that backed the hoook tools | 14:06 |
| fwereade_ | wallyworld, and it's responsible for returning the new state to the executor | 14:06 |
| wallyworld | sure, but i still need to determine how to intercept hook tool execution to set flag | 14:06 |
| fwereade_ | wallyworld, HookContext has a SetStatus method, right? | 14:07 |
| wallyworld | yes, but not acess to local state | 14:07 |
| wallyworld | so it can't set the flag from there | 14:07 |
| fwereade_ | wallyworld, right, but it shouldn't -- it can set its own local field | 14:07 |
| wallyworld | but that won't work | 14:07 |
| wallyworld | the flag needs to be persisted between calls | 14:07 |
| fwereade_ | wallyworld, but the operation can *read* that field, via some method on the runner.Context impl, and use it to set the state that gets persisted | 14:08 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | oh, i think i see what you mean | 14:08 |
| fwereade_ | wallyworld, cool | 14:09 |
| wallyworld | sorry, being really stupid tonight | 14:09 |
| fwereade_ | wallyworld, no worries at all | 14:09 |
| fwereade_ | wallyworld, but, uh, shouldn't you be in bed or something? ;p | 14:09 |
| wallyworld | yeah, but wanted to ensure i had this figured out | 14:10 |
| fwereade_ | wallyworld, cool :) | 14:10 |
| wallyworld | i think i was confusing that the status-set needed to store state | 14:10 |
| wallyworld | when it didn't have to | 14:10 |
| wallyworld | as it would be caled from inside a hook | 14:10 |
| fwereade_ | wallyworld, yeah, teasing out the layers there is kinda tricky | 14:10 |
| wallyworld | so the hook execution could set the state | 14:10 |
| wallyworld | sorry, i feel stupid now, it seems a lot more obvious than 10 mins ago | 14:11 |
| fwereade_ | wallyworld, no worries at all | 14:11 |
| wallyworld | thanks for you eternal patience :-) | 14:11 |
| fwereade_ | wallyworld, if there's anything I've said that you think could go into a useful comment in a judicious place please add one :) | 14:11 |
| fwereade_ | wallyworld, a pleasure | 14:11 |
| wallyworld | i might just do that | 14:11 |
| fwereade_ | ty | 14:12 |
| wallyworld | i'll be a uniter expert before the end of the week :-) | 14:12 |
| fwereade_ | awesome, I need more of those ;p | 14:12 |
| wallyworld | indeed | 14:12 |
| wallyworld | but now i need sleep, catch you later | 14:12 |
| fwereade_ | wallyworld, sleep well :) | 14:12 |
| === kadams54-away is now known as kadams54 | ||
| fwereade_ | can anyone think offhand why provider/dummy.state.apiServer.Stop() might be hanging? | 14:17 |
| fwereade_ | just in one test, I suspect I'm being dense :-/ | 14:18 |
| fwereade_ | but we reset the dummy provider about a million times per test run so it usually works pretty well :/ | 14:18 |
| jw4 | fwereade_: the only 'obvious' possibility seems to be some sort of deadlock with the tomb mutex? | 14:25 |
| jw4 | fwereade_: the nexus of Kill, Wait, and Err *might* have a potential conflict, but I don't see it yet | 14:26 |
| jw4 | fwereade_: I just don't see it. Is the hanging test reproducible? | 14:36 |
| cherylj | ericsnow: Looks like there's one more repo that needed that copyright update, and strikov made the change. Can you review / merge? https://github.com/juju/utils/pull/120 | 14:51 |
| ericsnow | cherylj: you bet | 14:52 |
| ericsnow | cherylj: do you know if all the changes have been applied in all three branches (1.22, 1.23, master)? | 14:53 |
| cherylj | ericsnow: gah, I think I missed 1.23 for juju/juju | 14:54 |
| cherylj | I'll do that now | 14:54 |
| ericsnow | cherylj: I suppose that matters mostly just for the juju repo, but the revision in dependencies.tsv for the different repos on each of those juju/juju branches needs to have the updated LICENCE file, so it may require some trickery | 14:55 |
| ericsnow | cherylj: by trickery I mean that in some cases we may need to add a branch on the other repo at the revision from dependencies.tsv and update the LICENCE there (and then update dependencies.tsv) | 14:56 |
| ericsnow | cherylj: that is because we may have made changes in the other repo since then that should not be included (via imports) into the older juju branch | 14:57 |
| ericsnow | cherylj: however, I couldn't tell you where that is the case | 14:57 |
| cherylj | ericsnow: I think I follow, but I'm not 100% :) | 14:57 |
| ericsnow | cherylj: the most likely candidate is the utils repo | 14:58 |
| ericsnow | cherylj: when in doubt, restate :) | 14:58 |
| ericsnow | cherylj: either way, dependencies.tsv needs to be updated on each of the 3 juju/juju branches in question | 14:59 |
| cherylj | But, updating it to the last commit for this license change may pull in changes we don't want? | 15:00 |
| ericsnow | natefinch: in case there is any ambiguity still, I *would* like a review on that patch if you can spare the time :) | 15:00 |
| mup | Bug #1436421 changed: juju panics after upgrade from 1.18.4 to 1.20.11 <panic> <status> <juju-core 1.20:Won't Fix> <https://launchpad.net/bugs/1436421> | 15:00 |
| mup | Bug #1436871 was opened: ppc64 gccgo fails to build cmd/juju <ci> <ppc64el> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1436871> | 15:01 |
| ericsnow | cherylj: that's exactly what I was trying to say with my long-winded blabbing :) | 15:01 |
| ericsnow | cherylj: FYI, that change to utils is merged now | 15:01 |
| ericsnow | cherylj: thanks for seeing this through | 15:01 |
| cherylj | ericsnow: hehe. Glad I understood. Should I just check what's changed between what's in the dependencies.tsv file and this latest version? | 15:02 |
| mup | Bug #1436655 changed: gce provider should stop using deprecated zone europe-west1-a <gce-provider> <juju-core:Won't Fix> <juju-core 1.23:Won't Fix> <https://launchpad.net/bugs/1436655> | 15:07 |
| TheMue | damdidamdidam - my vmaas is bootstrapping *dance* | 15:10 |
| mup | Bug #1436421 was opened: juju panics after upgrade from 1.18.4 to 1.20.11 <canonical-is> <panic> <status> <juju-core:Incomplete> <juju-core 1.20:Won't Fix> <https://launchpad.net/bugs/1436421> | 15:37 |
| TheMue | dooferlad: ping | 15:54 |
| dooferlad | TheMue: hi | 15:54 |
| TheMue | dooferlad: heya, I need networking support ;) | 15:54 |
| dooferlad | TheMue: sure. Hangout? IRC/ | 15:55 |
| TheMue | dooferlad: can be done here. my development VM has a fixed IP here in the local net, the MAAS controller VM another one as well as a private net on eth1. the MAAS nodes are all in this private net. | 15:56 |
| TheMue | dooferlad: now I would like to reach the nodes from the development VM. | 15:56 |
| TheMue | dooferlad: is it possible by routing or do I have to add another eth with the private net to that VM too? | 15:57 |
| dooferlad | TheMue: add another ethernet controller to the development VM and attach it to the private network | 15:57 |
| dooferlad | TheMue: The alternatives are messy. | 15:58 |
| cherylj | jam: Regarding the juju AGPL license - should I modify the text to only state v3? or is there someone I should check with regarding the "or later" statement? | 15:58 |
| TheMue | dooferlad: ok, already thought so, only needed confirmation | 15:58 |
| dooferlad | TheMue: no problem. Hope it is easy and works. | 15:59 |
| TheMue | dooferlad: should be, I'll report | 15:59 |
| TheMue | dooferlad: less woth then open a physical machine and add another card (after buying it) | 16:00 |
| TheMue | s/woth/work/ | 16:00 |
| TheMue | thick fingers | 16:00 |
| dooferlad | TheMue: Funny, I did the physical machines option because it seemed easy. I have so many bits of spare networking equipment! | 16:01 |
| dooferlad | I also like playing with hardware. | 16:01 |
| TheMue | dooferlad: I once had too, but then I gave most stuff away | 16:01 |
| TheMue | dooferlad: I don't need much HW, a little mainframe in the cellar would be enough. lets say 128 cores, also 128 Gig of RAM, and maybe 4 to 8 TB of SSDs *cough* *cough* | 16:03 |
| dooferlad | TheMue: my hardware doesn't quite stretch to that. I have plenty of storage, but not *all* SSD. | 16:04 |
| TheMue | dooferlad: I have to admit that my current laptop is more than enough for most tasks | 16:05 |
| TheMue | dooferlad: i7, 16 GB, 512 GB SSD, nothing special but a fine workhorse | 16:06 |
| natefinch | cherylj: we talked this over in a meeting this morning. It needs to be v3 only, no "or later" | 16:06 |
| dooferlad | TheMue: I also only have 42 cores around the house, maybe half of those are hyperthreaded. | 16:06 |
| cherylj | thanks, natefinch. I'll change it. | 16:06 |
| natefinch | cherylj: welcome, thanks for doing the work to get it in. | 16:06 |
| dooferlad | TheMue: in actual running hardware that is. | 16:07 |
| dooferlad | TheMue: When I had more ARM dev kit around the number of cores went way up. I am not counting phones and tablets, because that gets silly. | 16:08 |
| TheMue | dooferlad: yes, those 8 of the i7 are hyperthreaded too, 4 physical core | 16:08 |
| dooferlad | TheMue: Oh, those 42 cores probably look more like 60 to hardware :-) | 16:08 |
| TheMue | dooferlad: would like the high amount of cores in one computer to let go or erlang applications scale out a bit | 16:08 |
| dooferlad | TheMue: Ah, I rarely find anything CPU limited *and* able to scale past 8 cores. | 16:09 |
| TheMue | dooferlad: hehe yes, phones, thinking of Apache Mesos building one virtual computer out of all resources including phones and tablets, would be strange | 16:10 |
| ericsnow | jam: ping | 16:10 |
| TheMue | dooferlad: calculating large pis | 16:10 |
| dooferlad | TheMue: Oh, how useful :p | 16:10 |
| dooferlad | TheMue: http://en.wikipedia.org/wiki/Rainbow_table is a much better use of CPU time. | 16:11 |
| TheMue | dooferlad: yep, sounds good | 16:20 |
| TheMue | dooferlad: sorry for late answer, had to move my car, neighbor fells a tree | 16:21 |
| dooferlad | TheMue: sounds like a good reason to move your car! | 16:21 |
| TheMue | dooferlad: indeed | 16:21 |
| * ericsnow lols at $$irony$$ message in https://github.com/juju/juju/pull/1942 | 16:25 | |
| mup | Bug #1436421 changed: (1.20.11, 1.21) juju status panics when no .jenv is present <canonical-is> <panic> <status> <juju-core:Invalid> <juju-core 1.20:Won't Fix> <https://launchpad.net/bugs/1436421> | 16:43 |
| mup | Bug #1436925 was opened: juju status complains "config has no UUID" when no .jenv is present <canonical-is> <regression> <status> <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1436925> | 16:43 |
| mup | Bug #1436930 was opened: juju ssh --debug is not showing full ssh command used <juju-core:New> <https://launchpad.net/bugs/1436930> | 16:43 |
| TheMue | dooferlad: btw, the adding of the second network card worked. now there's the next hurdle | 16:49 |
| dooferlad | TheMue: cool | 16:49 |
| TheMue | dooferlad: hmm, juju now complains it cannot reach the maas controller *hmpf* but I already have an idea | 16:50 |
| dooferlad | TheMue: when you have a moment, could you help with creating some command tests. They are fine until I create an API client, at which point I get the error "no environment specified" | 16:51 |
| dooferlad | TheMue: It seems like I need to create a test environment, but it isn't clear to me how. | 16:52 |
| TheMue | dooferlad: gnah, the API server has been initialized with the public eth0 address of the MAAS controller, not its private counterpart on eth1 | 16:52 |
| dooferlad | TheMue: Oh, yea, that. | 16:52 |
| TheMue | dooferlad: sure, will help with the test | 16:53 |
| dooferlad | TheMue: I think I re-installed the MAAS server, because the second time around it asked what IP address / interface it should have | 16:53 |
| TheMue | dooferlad: AFAIK sudo dpkg-reconfigure maas-region-controller is enough to specify that address. so I'll do it | 16:54 |
| dooferlad | TheMue: it is | 16:54 |
| dooferlad | TheMue: Probably easier than changing all the references to the MAAS URL in /etc/maas (there are 6) | 16:55 |
| dooferlad | TheMue: If you sign up for an account on https://c9.io/ you can easily poke around my code. You don't need to pay. | 16:56 |
| TheMue | omw | 16:56 |
| dooferlad | TheMue: let me know your username once you are signed up so I can share my workspace. | 16:58 |
| TheMue | dooferlad: in there | 16:58 |
| dooferlad | TheMue: are you "themue"? | 16:59 |
| TheMue | dooferlad: exactly | 16:59 |
| TheMue | dooferlad: always trying to claim it | 16:59 |
| dooferlad | TheMue: you should have an invite to https://ide.c9.io/dooferlad/homework2golang | 17:00 |
| TheMue | dooferlad: yes, I'm in now | 17:00 |
| cherylj | Can I get another review for the license work? These are the changes for using only v3: http://reviews.vapour.ws/r/1289/ http://reviews.vapour.ws/r/1287/ | 17:07 |
| cherylj | And one for utils (1.22) http://reviews.vapour.ws/r/1288/ | 17:08 |
| niedbalski | axw_, ping | 17:19 |
| jw4 | OCR PTAL : Fix for blocker bug 1436871 http://reviews.vapour.ws/r/1291/ | 17:30 |
| mup | Bug #1436871: ppc64 gccgo fails to build cmd/juju <ci> <ppc64el> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1436871> | 17:30 |
| ericsnow | cherylj: thanks for working through all those changes for the copyright! | 17:44 |
| cherylj | ericsnow: np! | 17:44 |
| cherylj | ericsnow: I'm not sure if I still need to review the dependencies based off of strikov's comment in the bug | 17:45 |
| ericsnow | cherylj: am I right that all the relevant repos have been updated (or have a pending PR)? | 17:45 |
| cherylj | ericsnow: yes, I believe so | 17:45 |
| cherylj | Once they are merged, I can look at updating the dependencies.tsv file if we need to | 17:46 |
| ericsnow | cherylj: yeah, we still need the dependencies.tsv updated for the 3 juju/juju branches | 17:46 |
| cherylj | ok | 17:46 |
| cherylj | yeah, I'll do that once the merges complete | 17:46 |
| cherylj | ericsnow: you were mostly concerned with utils and juju 1.22? | 17:47 |
| ericsnow | cherylj: the contents of that file determine which revision of the various dependencies get packaged into the juju source release package, including the LICENCE file | 17:47 |
| ericsnow | cherylj: the release package having the correct LICENCE files is what we're blocked on for 1.22 | 17:48 |
| cherylj | ok | 17:48 |
| ericsnow | cherylj: so you're help has been very...helpful :) | 17:48 |
| mgz | jw4: how did you repo bug 1436871? | 17:53 |
| mup | Bug #1436871: ppc64 gccgo fails to build cmd/juju <ci> <ppc64el> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1436871> | 17:53 |
| jw4 | mgz: go build -compiler gccgo ./... | 17:53 |
| mgz | I had an issue where it builds fine on my dev machine (from tarball used or master) and fails differently on stilson-07 | 17:53 |
| jw4 | mgz: I updated the bug with my version of gccgo | 17:53 |
| jw4 | mgz: could be different version of gccgo.. it's clearly (to me) a gccgo bug | 17:54 |
| mgz | jw4: I have the same gccgo, and tried both in my tree, and in a new gopath with the tarball | 17:54 |
| jw4 | mgz: weird - also I'm using go 1.3.3 although I'm not clear that makes any difference | 17:54 |
| mgz | jw4: I agree, but want to narrow down what exactly for handover and failed somewhat | 17:54 |
| mgz | jw4: it may I guess, my dev machine in go 1.2.1 | 17:56 |
| mgz | but so is our build machine | 17:57 |
| jw4 | mgz: interesting - is the build machine the ppc64 one? | 17:59 |
| mgz | cherylj: thanks for testing out all the new gating jobs for the subprojects with the license changes :) | 17:59 |
| mgz | jw4: yeah, but I'm being dumb or something and failing to get it to build at all there | 18:00 |
| jw4 | mgz: hmmm - does my patch make any difference on the build machine? | 18:00 |
| mgz | jw4: probably not, it fails on github.com/juju/xml | 18:01 |
| jw4 | mgz: urg | 18:01 |
| jw4 | :) | 18:01 |
| mgz | because it can't import encoding... that's just a forked package from go itself, and doesn't blow up on my machine... | 18:02 |
| cherylj | mgz: it was a nice side effect :) | 18:03 |
| mgz | cherylj: did tim explain what was up with juju/testing landing? some version mismatch thing with a dep? | 18:05 |
| cherylj | mgz: the extent of the explanation I received was "that landing test is screwed" | 18:06 |
| cherylj | so, I can't be of much help :) | 18:06 |
| mgz | ehehe, I'll poke him at some point :) | 18:06 |
| wwitzel3 | if there a way to set a unit with no actual backing machine to started / active and bypass the presencer? | 18:13 |
| wwitzel3 | I've tried SetStatus(Started) and SetAgentStatus(Active), but the unit itself will just revert back to down | 18:15 |
| niedbalski | Does there is any reason why 35d023f7 changed utils/ssh debugf statements to tracef? orselse, there is any way to display trace statements (such as --debug)? | 18:18 |
| natefinch | wwitzel3: I'm sort of surprised that doesn't work, since we've talked about proxy charms in the past.... but I don't know the details of how it's supposed to work. | 18:20 |
| natefinch | niedbalski: you can set logging-config in your environment config: juju environment set logging-config="<root>=DEBUG;juju.foo.bar=TRACE" | 18:22 |
| cherylj | ericsnow: so in going through dependencies.tsv, I see the problematic repos are: charm and names (loggo has some additional changes since the commit that's currently in dependencies.tsv, but they're all to a readme) | 18:25 |
| niedbalski | natefinch, thanks | 18:25 |
| cherylj | ericsnow: for 1.22 | 18:25 |
| mup | Bug #1436988 was opened: juju backup/restore is upstart-specific <backup-restore> <systemd> <vivid> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.23:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1436988> | 18:25 |
| ericsnow | cherylj: that sounds right | 18:26 |
| ericsnow | cherylj: how much has changed for those two since 1.22? | 18:26 |
| ericsnow | cherylj: if it's not much (and 1.22 passes with an updated dependencies.tsv) then we might be okay | 18:27 |
| wwitzel3 | natefinch: yeah, I was looking for something in the service or unit fields, thinking their might be bool I need to set to avoid the worker trying to ping the unit for status. | 18:28 |
| ericsnow | cherylj: otherwise we'll probably need a juju-1.22 branch on each and apply your LICENCE patch on those | 18:28 |
| cherylj | it's not nothing, but i haven't looked at the commits to see what they are. I can try to run tests locally with those changes and see what happens | 18:28 |
| ericsnow | cherylj: yeah, see if 1.22 still works :) | 18:28 |
| cherylj | k | 18:28 |
| natefinch | ericsnow, cherylj: yeah, I just realized, with our use of godeps, we're kind of screwing ourselves by not having separate branches for each release for the dependent branches, if we need to "go back in time" and fix something without applying any of the new changes. | 18:29 |
| ericsnow | natefinch: do you think we are okay to update the 1.22 deps if everything still passes? | 18:29 |
| natefinch | ericsnow: I'd be very careful about looking at what changed... tests can't catch everything | 18:30 |
| ericsnow | natefinch: I figured you'd say that :) | 18:31 |
| ericsnow | natefinch: (and I agree) | 18:31 |
| cherylj | natefinch, ericsnow: There are a lot of changes for charm v4: http://paste.ubuntu.com/10685349/ | 18:35 |
| ericsnow | cherylj: then we're probably going to have to branch at the revision currently in dependecies.yaml and do that dance | 18:36 |
| natefinch | yep | 18:36 |
| cherylj | ok, let me look at names too | 18:36 |
| cherylj | loggo should be fine. | 18:36 |
| ericsnow | cherylj: if there's *any* doubt we should do that same for names | 18:37 |
| wwitzel3 | is there code that specifically handles proxy charms? I can't seem to grep it | 18:38 |
| natefinch | ericsnow, cherylj: I'm not actually sure how we can branch it and have it work correctly w/ go, godeps, etc | 18:38 |
| cherylj | ericsnow: yes, we should branch names too. | 18:39 |
| natefinch | niemeyer: you around? | 18:40 |
| alexisb | natefinch, niemeyer is on vacation this week | 18:41 |
| natefinch | dang | 18:41 |
| niemeyer | Hey | 18:41 |
| alexisb | niemeyer, you are suppose to be on vacation :) | 18:41 |
| niemeyer | natefinch: What's up? | 18:41 |
| niemeyer | alexisb: I am! :-) | 18:42 |
| natefinch | niemeyer: we have to do some wacky branching for a repo that's using gopkg.in, and I'm not exactly sure the best way to do it. Thought you might have an idea. | 18:42 |
| niemeyer | natefinch: Ok, what's the case? | 18:43 |
| natefinch | niemeyer: we're using gopkg.in/juju/charm.v4 in 1.22 using godeps to pin the revision to something before HEAD... now we have to make a change to that code to update the LICENSE. However, there are changes past where we're pinned in v4 that we don't really want to include in 1.22 | 18:43 |
| ericsnow | natefinch: we did it with utils and it worked out fine | 18:44 |
| natefinch | niemeyer: there's already a charm.v5-unstable | 18:44 |
| ericsnow | natefinch: oh, gopkg.in... | 18:44 |
| natefinch | yes | 18:44 |
| niemeyer | natefinch: gopkg.in doesn't really bring anything out of the ordinary to that picture | 18:45 |
| niemeyer | You need a revision that has the content you want, and the branch or tag needs to point to it | 18:45 |
| natefinch | ...and go get w/godeps needs to be able to get that revision | 18:46 |
| natefinch | my problem is, it;'s not like we can make a 1.22 branch for the repo... because gopkg.in would then serve that up to people asking for v1 and go get can't get that branch by itself. | 18:48 |
| natefinch | I am assuming that godeps can't set the code to a random commit that isn't on the branch you've downloaded with go get | 18:49 |
| natefinch | it sort of seems like our only options are: make a v6 (or something) that uses gopkg.in (which is bad because it's not actually a later version than v5).... or just make a new repo called github.com/juju/charm.v4.1.22 and have go get point to the head of that repo. Which is ugly, but works. | 18:50 |
| niemeyer | natefinch: You mean pointing v4 to something other that v4, despite the fact you have a branch or tag explicitly named v4? | 18:50 |
| natefinch | niemeyer: right, so, we have code later in the v4 branch that we don't want to include in 1.22, but we need a change on top of what we're using in 1.22's pinned version of v4 | 18:51 |
| niemeyer | natefinch: You can have a tag v4.1 for example | 18:52 |
| niemeyer | (or a branch) | 18:53 |
| niemeyer | This is well documented at http://gopkg.in, under "Version number" | 18:53 |
| natefinch | niemeyer: but won't gopkg.in serve up that branch if you ask for gopkg.in/juju/charm.v4? | 18:53 |
| natefinch | niemeyer: I assume we have other code that will ask for charm.v4 that wants the actual v4 branch | 18:54 |
| niemeyer | natefinch: v4.1 > v4 | 18:54 |
| niemeyer | natefinch: so the change is incompatible? | 18:55 |
| mup | Bug #1427257 changed: Juju backup doesn't contain .juju files <backup-restore> <cts> <juju-core:Won't Fix> <https://launchpad.net/bugs/1427257> | 18:55 |
| mup | Bug #1436930 changed: juju ssh --debug is not showing full ssh command used <juju-core:Invalid> <https://launchpad.net/bugs/1436930> | 18:55 |
| niemeyer | natefinch? | 18:59 |
| natefinch | niemeyer: it's not incompatible. it's actually just in the license, so it doesn't affect the code at all. I guess if we branch, add the new commit, and then merge over the later changes from v4, that should work, as long as the commit numbers stay the same in the new branch | 19:00 |
| ericsnow | natefinch: so v4.1 will effectively be an earlier revision than v4... | 19:00 |
| natefinch | it's a matter of making sure that existing code that targets v4 will still be able to use the same commit numbers to pin their code to the same functionality | 19:02 |
| natefinch | if gopkg.in delivers a different branch without those revisions, godeps will try to update to the revision and fail | 19:02 |
| natefinch | ericsnow: v4.1 will be identical to v4 with one inserted revision in the "past" which thankfully will be in a file that no one else should be touching. | 19:03 |
| ericsnow | natefinch: so if we weren't using gopkg.in none of this would be a problem... | 19:04 |
| niemeyer | natefinch: So there's no reason for people to want the "old v4".. | 19:04 |
| niemeyer | Also, git has no commit number, precisely because they are not stable | 19:05 |
| niemeyer | So you can just branch off and tag | 19:05 |
| natefinch | ericsnow: not really... because gopkg.in is the only thing letting us use branches at all | 19:05 |
| niemeyer | ericsnow: If we had no juju, none of that would be a problem as well.. In fact, without computers we'd have no software problems whatsoever! Hmm.. | 19:07 |
| ericsnow | niemeyer: :) | 19:07 |
| cherylj | ericsnow, natefinch: Should I make the changes to dependencies.tsv for the other repos? or wait until names and charm have the new repo? | 19:13 |
| jw4 | what... no one want's master unblocked? c'mon http://reviews.vapour.ws/r/1291/ :) | 19:13 |
| jw4 | s/want's/wants/ | 19:13 |
| ericsnow | cherylj: I say just wait until all the ducks are lined up | 19:13 |
| cherylj | ericsnow: okay, I'm going to grab some lunch. bbiab | 19:14 |
| mgz | jw4: oooo | 19:16 |
| jw4 | mgz: :) | 19:16 |
| mgz | you are still a master of getting things to break | 19:16 |
| jw4 | uh oh | 19:17 |
| mgz | jw4: landit | 19:17 |
| jw4 | mgz: gratzie | 19:17 |
| mgz | jw4: so, what's still a mystery to me is what changed | 19:20 |
| jw4 | mgz: yeah, me too! | 19:20 |
| jw4 | I can't figure out anything significant that changed | 19:20 |
| mgz | those methods are all old, which makes me suspect something on the stilson machine got twiddled... which matches the env you have, but not the one I have | 19:20 |
| jw4 | mgz: I know I'm completely up to date in 14.04 with latest packages maybe something recent was installed that perturbed the force | 19:21 |
| mgz | well, that's worth checking | 19:23 |
| mgz | I don't have a new go or gcc incomimg, but do have a bunch of other packages to update | 19:24 |
| jw4 | mgz: only possibility I see so far is libc6 which was updated on my machine late Februrary | 19:30 |
| jw4 | version 2.19-0ubuntu6.6 | 19:30 |
| * jw4 makes lunch for kids | 19:31 | |
| mup | Bug #1437015 was opened: debug-log contains leader-election messages even when feature not enabled <landscape> <juju-core:New for fwereade> <https://launchpad.net/bugs/1437015> | 19:37 |
| voidspace | g'night all | 19:50 |
| mup | Bug #1436507 changed: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <intermittent-failure> <juju-core:Invalid by cmars> <https://launchpad.net/bugs/1436507> | 20:07 |
| mup | Bug #1437021 was opened: 1.23b2 some charms only listening on IPv6 <landscape> <juju-core:Triaged> <https://launchpad.net/bugs/1437021> | 20:07 |
| ericsnow | cmars: thanks for looking into that bug | 20:19 |
| cherylj | I'm getting "local error: bad record MAC" when I'm trying to merge changes on 1.22. Any ideas what's causing it / how I can work around it? | 20:55 |
| === jog_ is now known as jog | ||
| jw4 | cherylj: I"m pretty sure that's an environmental issue - usually folks just retry | 21:04 |
| wallyworld | cherylj: that's a known bug with mongo 2.4 | 21:04 |
| cherylj | thanks, jw4. I was getting concerned as I've already retried a few times :) | 21:04 |
| cherylj | I'll keep at it. | 21:04 |
| wallyworld | won't be fixed in the 2.4 series AFAIK | 21:04 |
| cherylj | thanks, wallyworld | 21:05 |
| mup | Bug #1383346 changed: Remove rsyslog configuration from agent/units <cts-cloud-review> <logging> <rsyslog> <juju-core:Invalid> <https://launchpad.net/bugs/1383346> | 21:11 |
| mup | Bug #1437038 was opened: 1.23b2 fails to get IP from MAAS for containers, falls back to lxcbr0 <juju-core:New> <https://launchpad.net/bugs/1437038> | 21:11 |
| mup | Bug #1437040 was opened: unit test failure: TestNewDefaultServer.N40_github_com_juju_juju_cert_test.certSuite <ci> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1437040> | 21:11 |
| cherylj | ericsnow: what's the verdict about new names / charm branches for this licensing issue? I haven't seen any further discussion | 21:22 |
| ericsnow | cherylj: natefinch and I chatted about it and determined we can just go with a 1.22 branch (like we've done for utils), even with charms | 21:23 |
| cherylj | ericsnow: ok, cool. Who's on the hook for creating that? :) | 21:25 |
| ericsnow | cherylj: I'm not sure how we handle new branches on github | 21:26 |
| ericsnow | cmars: do you know? ^^^ | 21:26 |
| cmars | what's the branch we want to create? | 21:27 |
| cmars | ericsnow, cherylj ^^ | 21:27 |
| ericsnow | cmars: on the charms repo, 1.22 | 21:28 |
| cmars | oh | 21:28 |
| ericsnow | cmars: we needed on the names repo too (right, cherylj?) | 21:28 |
| cmars | ericsnow, cherylj, github.com/juju/charm, you mean? | 21:29 |
| ericsnow | cmars: we already have one on the utils repo | 21:29 |
| cmars | ericsnow, why are we branching dependent projects in lockstep with juju? | 21:29 |
| cmars | cherylj, ^^ | 21:29 |
| ericsnow | cmars: we need changes at the revision on which 1.22 depends | 21:30 |
| ericsnow | cmars: and not get newer changes on the repos | 21:30 |
| cmars | ericsnow, run godeps from the juju 1.22 branch? | 21:30 |
| ericsnow | cmars: right, and we need a fix on top of that revision | 21:31 |
| ericsnow | cmars: (fix the LICENCE file) | 21:31 |
| mup | Bug #1277086 changed: Add redirection of the logs to remote rsyslog server <cts> <cts-cloud-review> <feature> <juju-core:Invalid> <https://launchpad.net/bugs/1277086> | 21:32 |
| mup | Bug #1393434 changed: juju resolved -r does not solve hook error after node failure <cts> <resolved> <juju-core:Invalid> <https://launchpad.net/bugs/1393434> | 21:32 |
| cmars | ericsnow, oh, ok. well, if its in another project, perhaps juju-1.22 is a better name for the branch, as it indicates the consumer of the branch. 1.22 is probably fine | 21:32 |
| ericsnow | cmars: I feel the same way, but natefinch suggested we repeat what we did for utils (just "1.22") | 21:33 |
| cmars | ericsnow, wfm, we'll all probably know what that means :) | 21:33 |
| ericsnow | cmars: k | 21:33 |
| cmars | ericsnow, cherylj ok, so hows about i make the branches on these two projects off the 1.22 revnos in that godeps, and then y'all can propose PRs into them? | 21:34 |
| ericsnow | cmars: I'm just not sure how to create a branch on github (with the bot and all) | 21:34 |
| cmars | i think I can push into them. let's find out! | 21:34 |
| ericsnow | cmars: :) | 21:34 |
| cherylj | cmars: sounds good, let's give it a try :) | 21:34 |
| cmars | ericsnow, i'm not sure how things land in those projects. uiteam owns juju/charm, perhaps sinzui knows about how the bot lands things into names | 21:35 |
| ericsnow | mgz: ^^^ ? | 21:35 |
| mgz | jw4: yeah, I can do that | 21:36 |
| mgz | ericsnow: ^ | 21:36 |
| mgz | cmars should be able to as well | 21:36 |
| ericsnow | cmars: you got that? ^ | 21:36 |
| cmars | yep | 21:36 |
| mgz | the bot handles branches just as-is | 21:36 |
| mgz | create on github, propose merge against that branch rather than master, bot will pick up, test, and land against the right thing | 21:37 |
| ericsnow | mgz: that's what I figured | 21:37 |
| mgz | juju/charm isn't gated currently, because of the multi-team overlap and no okay on it, so that can just me merge-buttoned on the pr page | 21:38 |
| mgz | but we probably do want to gate it as well | 21:38 |
| cmars | ericsnow, cherylj you can propose the change to juju/charm with a PR into the v4 branch. that import uses gopkg anyway, so a 1.22 branch won't work for that one | 21:41 |
| cmars | ericsnow, cherylj i'll push a 1.22 branch for names | 21:41 |
| ericsnow | cmars: a 1.22 branch should work fine for the charm repo | 21:42 |
| ericsnow | cmars: natefinch checked this earlier | 21:42 |
| cmars | ericsnow, ah, sneaky | 21:42 |
| cmars | ericsnow, yeah, i can see how that might work | 21:42 |
| cmars | ok | 21:43 |
| cherylj | hehe | 21:43 |
| ericsnow | cmars: yeah, so we'll do the same thing for both | 21:43 |
| cmars | cherylj, ericsnow ok, created your branches. propose PRs and I can push the button if landing bot can't do it | 21:49 |
| cherylj | cmars: ok, just a minute... | 21:49 |
| cherylj | while I'm in here, I see that charm also has the "v3 and later" verbiage. | 21:51 |
| cherylj | jam, should charm also be using AGPL v3 (and not later)? | 21:51 |
| cmars | cherylj, jam is probably well past eod | 21:54 |
| * cmars looks at the charm history | 21:54 | |
| cherylj | ok, I suspect to be safe we should restrict it to v3 | 21:55 |
| mgz | okay, so I remember, the issue with juju/charm is it doesn't work with all tips, but has a complex dep tree | 21:55 |
| mgz | so, is one of the projects that really needs its own dependencies.tsv | 21:55 |
| cmars | cherylj, +1, that's always the best way to go. if we like v4 we can relicense to say "v3 or v4" | 21:55 |
| cherylj | cmars: ok, I'm going to make that change here as well, then | 21:56 |
| cmars | cherylj, awesome, thanks! | 21:56 |
| mgz | cmars: I hate that approach in general, but the argument was had and ze top dislikes "or later" | 21:56 |
| cherylj | cmars: okay, I have the PR: https://github.com/juju/charm/pull/105 | 22:00 |
| cherylj | I'll work on names now too | 22:01 |
| mup | Bug #1414364 changed: juju 1.21 and 1.22 have conflicting product json rules <metadata> <juju-core:Won't Fix> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1414364> | 22:02 |
| mup | Bug #1427879 changed: juju cannot deploy when distro-info-data gets a new series <deploy> <series> <juju-core:Fix Released by wallyworld> <juju-core 1.22:Fix Committed by wallyworld> <juju-core 1.23:Fix Released by wallyworld> <https://launchpad.net/bugs/1427879> | 22:02 |
| cmars | cherylj, i'm sorry, i can't land these | 22:03 |
| cmars | https://www.gnu.org/licenses/gpl-howto.html | 22:03 |
| cmars | "You should also include a copy of the license itself somewhere in the distribution of your program. All programs, whether they are released under the GPL or LGPL, should include the text version of the GPL. In GNU programs the license is usually in a file called COPYING." | 22:04 |
| cmars | cherylj, who wants these changes? | 22:05 |
| cherylj | cmars: https://bugs.launchpad.net/juju-core/+bug/1435974 | 22:05 |
| mup | Bug #1435974: Copyright information is not available for some files <juju-core:In Progress by cherylj> <juju-core 1.22:In Progress by cherylj> <juju-core 1.23:In Progress by cherylj> <https://launchpad.net/bugs/1435974> | 22:05 |
| cherylj | cmars: I need to go eat dinner with my family, but I'll be back soon. I'll do whatever is deemed appropriate for these licensing changes, but maybe there needs to be a conversation held to make sure everyone's on the same page | 22:06 |
| cmars | cherylj, i'm marking this won't fix | 22:07 |
| cherylj | cmars: okay, but there are a lot of changes already landed for it. | 22:08 |
| cmars | cherylj, then i'll wait for the response there | 22:08 |
| cherylj | ok | 22:08 |
| mup | Bug #1414364 was opened: juju 1.21 and 1.22 have conflicting product json rules <metadata> <juju-core:Won't Fix> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1414364> | 22:08 |
| mup | Bug #1427879 was opened: juju cannot deploy when distro-info-data gets a new series <deploy> <series> <juju-core:Fix Released by wallyworld> <juju-core 1.22:Fix Committed by wallyworld> <juju-core 1.23:Fix Released by wallyworld> <https://launchpad.net/bugs/1427879> | 22:08 |
| wallyworld | waigani: hey there, have you seen bug 1436925 ? was raised recently against 1.23 beta1, might have been fixed already, but if not, is critical for 1.23 | 22:13 |
| mup | Bug #1436925: juju status complains "config has no UUID" when no .jenv is present <canonical-is> <regression> <status> <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1436925> | 22:13 |
| waigani | wallyworld: no, I didn't see that. I'll look into it now. | 22:14 |
| wallyworld | ty | 22:14 |
| waigani | wallyworld: thanks for the head's up | 22:14 |
| mup | Bug #1414364 changed: juju 1.21 and 1.22 have conflicting product json rules <metadata> <juju-core:Won't Fix> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1414364> | 22:14 |
| mup | Bug #1427879 changed: juju cannot deploy when distro-info-data gets a new series <deploy> <series> <juju-core:Fix Released by wallyworld> <juju-core 1.22:Fix Committed by wallyworld> <juju-core 1.23:Fix Released by wallyworld> <https://launchpad.net/bugs/1427879> | 22:14 |
| ericsnow | wallyworld: thanks for following up on that :) | 22:14 |
| wallyworld | sure | 22:15 |
| axw_ | niedbalski: pong | 22:53 |
| mup | Bug #1427257 was opened: Juju backup doesn't contain .juju files <backup-restore> <cts> <juju-core:In Progress> <https://launchpad.net/bugs/1427257> | 23:02 |
| mup | Bug #1427257 changed: Juju backup doesn't contain .juju files <backup-restore> <cts> <juju-core:In Progress> <https://launchpad.net/bugs/1427257> | 23:08 |
| Spizmar | Would this be the appropriate place to ask questions on charm setup of cgi-bin scripts? Not on the script, but on setting up cgi-bin in the charm? | 23:13 |
| mup | Bug #1427257 was opened: Juju backup doesn't contain .juju files <backup-restore> <cts> <juju-core:In Progress> <https://launchpad.net/bugs/1427257> | 23:14 |
| waigani | wallyworld: I think bug 1436925 is invalid, I've added a comment | 23:28 |
| mup | Bug #1436925: juju status complains "config has no UUID" when no .jenv is present <canonical-is> <regression> <status> <juju-core:Triaged> <juju-core 1.23:In Progress by waigani> <https://launchpad.net/bugs/1436925> | 23:28 |
| wallyworld | waigani: the issue is, 1.23 *must* be able to talk to envs without a jenv | 23:30 |
| wallyworld | for backwards compatability | 23:30 |
| wallyworld | as noted in the bug - "Since 1.18.4 supports environments that lack jenvs," | 23:30 |
| wallyworld | backwards-compatibility requires current jujus to support that. | 23:31 |
| wallyworld | so it does need to be fixed | 23:31 |
| wallyworld | this bug was raised by our IS people and they have a broekn production system because of it | 23:32 |
| waigani | wallyworld: okay. So we need to make a 1.23 client work without a .jenv file? | 23:33 |
| wallyworld | waigani: yes, also see bug 1436421 | 23:34 |
| mup | Bug #1436421: (1.20.11, 1.21) juju status panics when no .jenv is present <canonical-is> <panic> <status> <juju-core:Invalid> <juju-core 1.20:Won't Fix> <https://launchpad.net/bugs/1436421> | 23:34 |
| waigani | Yeah, I'm looking at that one | 23:34 |
| wallyworld | the panic is gone but it still doesn't work | 23:34 |
| wallyworld | according to the bug if i read correctly | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!